In the case you pass -object_path_lto without any IR files, the LTO
infrastructure attempts to derive the default triple and fails if none
is found. This sets the default triple to the one we've derived from
-platform_version / -arch.
Details
- Reviewers
- None
- Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Huh, I'm surprised that setting -object_path_lto has a functional difference; I thought it was only to make debugging the intermediate object files easier. Did you figure out why?
Also, did you figure out why LLD-ELF doesn't seem to need to set DefaultTriple?
lld/test/MachO/lto-object-path.ll | ||
---|---|---|
5 | how does compiling with llc different from compiling with opt? |
so the difference with elf is it just avoids this work all together, here's a patch with that option https://reviews.llvm.org/D145273 and the original commit for that logic https://github.com/llvm/llvm-project/commit/f3994e4dfa0214b2a09a0e327ba37e6b38bbcdb3
with this patch the object_path_lto file ends up getting created and is empty, so technically the other patch would be less work, although I doubt it's meaningful perf wise
lld/test/MachO/lto-object-path.ll | ||
---|---|---|
5 | the difference is that we want an object file here and the opt calls are producing bitcode files |
lld/test/MachO/lto-object-path.ll | ||
---|---|---|
5 | d'oh, of course :) |
how does compiling with llc different from compiling with opt?