Skip to content

[clang] Move opt level in clang toolchain to clang::ConstructJob start #141036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

omarahmed1111
Copy link
Contributor

We currently transfer the opt level from the user clang call to CC1 args at the end of the ConstructJob function, this might lead to bugs as ConstructJob is a big function and we easily could add a change that would return early from it. That would cause the opt level to not be transferred to CC1 args and lead to wrong opt level compilation and would be hard to spot. This PR moves the opt level to the beginning of the function as opt level should be a direct transfer without any problems, it also removes the redundancy where it was added 2 times through the function.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels May 22, 2025
@llvmbot
Copy link
Member

llvmbot commented May 22, 2025

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-driver

Author: Omar Ahmed (omarahmed1111)

Changes

We currently transfer the opt level from the user clang call to CC1 args at the end of the ConstructJob function, this might lead to bugs as ConstructJob is a big function and we easily could add a change that would return early from it. That would cause the opt level to not be transferred to CC1 args and lead to wrong opt level compilation and would be hard to spot. This PR moves the opt level to the beginning of the function as opt level should be a direct transfer without any problems, it also removes the redundancy where it was added 2 times through the function.


Full diff: https://github.com/llvm/llvm-project/pull/141036.diff

1 Files Affected:

  • (modified) clang/lib/Driver/ToolChains/Clang.cpp (+10-20)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index 355a48be9f493..30ecbf865d261 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5202,6 +5202,16 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
     }
   }
 
+  // Optimization level for CodeGen.
+  if (const Arg *A = Args.getLastArg(options::OPT_O_Group)) {
+    if (A->getOption().matches(options::OPT_O4)) {
+      CmdArgs.push_back("-O3");
+      D.Diag(diag::warn_O4_is_O3);
+    } else {
+      A->render(Args, CmdArgs);
+    }
+  }
+
   // Unconditionally claim the printf option now to avoid unused diagnostic.
   if (const Arg *PF = Args.getLastArg(options::OPT_mprintf_kind_EQ))
     PF->claim();
@@ -5573,16 +5583,6 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
       break;
     }
 
-    // Optimization level for CodeGen.
-    if (const Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-      if (A->getOption().matches(options::OPT_O4)) {
-        CmdArgs.push_back("-O3");
-        D.Diag(diag::warn_O4_is_O3);
-      } else {
-        A->render(Args, CmdArgs);
-      }
-    }
-
     // Input/Output file.
     if (Output.getType() == types::TY_Dependencies) {
       // Handled with other dependency code.
@@ -6463,16 +6463,6 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
   // preprocessed inputs and configure concludes that -fPIC is not supported.
   Args.ClaimAllArgs(options::OPT_D);
 
-  // Manually translate -O4 to -O3; let clang reject others.
-  if (Arg *A = Args.getLastArg(options::OPT_O_Group)) {
-    if (A->getOption().matches(options::OPT_O4)) {
-      CmdArgs.push_back("-O3");
-      D.Diag(diag::warn_O4_is_O3);
-    } else {
-      A->render(Args, CmdArgs);
-    }
-  }
-
   // Warn about ignored options to clang.
   for (const Arg *A :
        Args.filtered(options::OPT_clang_ignored_gcc_optimization_f_Group)) {

@omarahmed1111 omarahmed1111 changed the title [Clang] Move opt level in clang toolchain to beginning [Clang] Move opt level in clang toolchain to clang::ConstructJob start May 22, 2025
@omarahmed1111 omarahmed1111 force-pushed the move-opt-level-addition-in-clang-toolchain branch from 905a0a1 to 0eb7547 Compare May 22, 2025 14:49
@omarahmed1111 omarahmed1111 changed the title [Clang] Move opt level in clang toolchain to clang::ConstructJob start [clang] Move opt level in clang toolchain to clang::ConstructJob start May 22, 2025
@omarahmed1111
Copy link
Contributor Author

@tarunprabhu @florianhumblot @alexey-bataev @RKSimon @phoebewang Not sure who to as for review, so please review or if you could mention who is responsible for reviewing this code, Thanks!

@RKSimon RKSimon requested review from Artem-B and jhuber6 May 22, 2025 21:27
Copy link
Contributor

@tarunprabhu tarunprabhu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Any cleanup of this code is helpful.

@omarahmed1111
Copy link
Contributor Author

@Artem-B @tarunprabhu Could you merge it for me as I don't have access, Thanks!

@tarunprabhu tarunprabhu merged commit 06ee672 into llvm:main May 28, 2025
11 checks passed
sivan-shani pushed a commit to sivan-shani/llvm-project that referenced this pull request Jun 3, 2025
llvm#141036)

We currently transfer the opt level from the user clang call to CC1 args
at the end of the `ConstructJob` function, this might lead to bugs as
`ConstructJob` is a big function and we easily could add a change that
would return early from it. That would cause the opt level to not be
transferred to CC1 args and lead to wrong opt level compilation and
would be hard to spot. This PR moves the opt level to the beginning of
the function as opt level should be a direct transfer without any
problems, it also removes the redundancy where it was added 2 times
through the function.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants