Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
It looks like this is part of the required fix for PR30403? I guess the other part is to add the module flag to be set during the FE, and use that to set this flag?
It would be good to add support in the new LTO API too.
In the discussion on PR30403 it sounds like the desired behavior was closer to -ffreestanding than -fno-builtin, so should the variable names reflect that?
llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h | ||
---|---|---|
146 ↗ | (On Diff #91215) | Why not instead add this flag as a member of LTOCodeGenerator, similar to what you do for the ThinLTOCodeGenerator? |
llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h | ||
209 ↗ | (On Diff #91215) | document |
llvm/test/ThinLTO/X86/tli-nobuiltin.ll | ||
38 ↗ | (On Diff #91215) | s/fputs/fwrite/ per earlier checks? |
This is a lame but pragmatic way of going around the issue and allow our kernel to be built with ThinLTO ;)
The plan for the "clean solution" in the future is to embed the information in function-level attributes. But it'll take too much time for me to accomplish right now (and in the 5.0 timeframe FWIW).
It would be good to add support in the new LTO API too.
In the discussion on PR30403 it sounds like the desired behavior was closer to -ffreestanding than -fno-builtin, so should the variable names reflect that?
The discussion on clang-dev blurred the lines between -ffreestanding and -fno-builtin, to the point where I gave up trying to differentiate them.
llvm/include/llvm/LTO/legacy/LTOCodeGenerator.h | ||
---|---|---|
146 ↗ | (On Diff #91215) | I just tried to fit into the existing by mimicking DisableVectorization. That said I think I can do differently (see below). |
llvm/include/llvm/LTO/legacy/ThinLTOCodeGenerator.h | ||
209 ↗ | (On Diff #91215) | Will do! |
llvm/test/ThinLTO/X86/tli-nobuiltin.ll | ||
38 ↗ | (On Diff #91215) | Oh right! |
llvm/tools/lto/lto.cpp | ||
165 ↗ | (On Diff #91215) | I likely can set the DisableLTOBuiltins on the CodeGenerator here. |
If this is just a temporary solution for one specific application, does it really need first class support in the clang driver? Would it not be sufficient for you to pass -Wl,-mllvm,-lto-nobuiltin at link time?
I also have a mild preference to use the term "freestanding" for this.
Sure. I'm fine dropping the clang part.
I also have a mild preference to use the term "freestanding" for this.
I don't mind.
Address comments:
- set Freestanding as a member of LTOCodegenerator
- document the setter
- drop the clang driver changes
You may want to include the freestanding flag in the code generation options hash.
Aside from that, LGTM.