[PATCH] D141970: [Clang][LLD] Add --lto-CGO[0-3] option

Scott Linder via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 20 13:05:40 PST 2023


scott.linder added inline comments.


================
Comment at: lld/Common/Args.cpp:20
 
-// TODO(sbc): Remove this once CGOptLevel can be set completely based on bitcode
-// function metadata.
----------------
pcc wrote:
> This is still the preferred approach.
I can move the comment, I just wasn't sure where to should go now.


================
Comment at: lld/ELF/Driver.cpp:1143
+  config->ltocgo =
+      *CodeGenOpt::getLevel(args::getInteger(args, OPT_lto_CGO, config->ltoo));
   config->ltoObjPath = args.getLastArgValue(OPT_lto_obj_path_eq);
----------------
pcc wrote:
> It looks like this is setting the CG opt level based on the LTO opt level, which is undesirable for the reasons mentioned in D57422. Let's keep the existing logic for determining the default CG opt level.
Right, but the existing `lld::args::getCGOptLevel` is also setting the CG opt level based on the LTO opt level, just in a surprising manner (i.e. not 1:1). I saw this same concern in a comment on D57422 by @mehdi_amini but didn't see any response.

I find it confusing that a new user of LTO would start with a command-line like this and observe that they got `CodeGenOpt::None`:

```
$ echo 'int main() {}' | build/bin/clang -### -x c -O0 -
"clang" "-cc1" "-emit-obj" "-O0" ...
"ld.lld" ...
```

And that by adding just `-flto` they would still see command-lines for CC1 and the linker that would indicate the same would be true:

```
$ echo 'int main() {}' | build/bin/clang -### -x c -O0 - -flto
"clang" "-cc1" "-emit-llvm-bc" "-O0" ...
"ld.lld" "-plugin-opt=O0" ...
```

And yet somehow they get `CodeGenOpt::Default` behavior (and before this patch would have no recourse to correct this).

It isn't obvious to me (and I assume a typical user of Clang) that the internal behavior when adding "-flto" is that the CG opt level cannot ever fall below `Default`.

If we really need to retain the special behavior in the linkers themselves, could we instead teach Clang to start passing the new option, so the above becomes:

```
$ echo 'int main() {}' | build/bin/clang -### -x c -O0 - -flto
"clang" "-cc1" "-emit-llvm-bc" "-O0" ...
"ld.lld" "-plugin-opt=O0" "--lto-CGO0" ...
```

?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D141970/new/

https://reviews.llvm.org/D141970



More information about the llvm-commits mailing list