Differential D150930
[Driver] Accept and ignore -fno-lifetime-dse argument Authored by thesamesam on May 18 2023, 7:58 PM.
Details Since 47f5c54f997a59bb2c65abe6b8b811f6e7553456, we pass -fno-lifetime-dse Unfortunately, this impacts projects which build LLVM using GCC who then try While we're trying to stop adding these, given we're passing the flag ourselves,
Diff Detail
Unit Tests Event TimelineComment Actions This is just a draft which I've only briefly tested so far. I'm wondering if this is the right place to put the option, as i've not had to write anything in tablegen before. Comment Actions I object to parse and ignore this GCC option, which appears obscure. The original request to accept -fno-lifetime-dse is so that someone's clang-tidy or other clang tooling can accept compile_commands.json produced by GCC. While GCC and Clang share many options, there are also many that Clang don't recognize. For a useful option, we consider implementing it, but I think the bar is higher than appeasing such unsupported use cases. For example, I keep Linux kernel builds with both GCC and Clang. I use the Clang one for ccls (a language server) but the GCC one for debugging. // from 2019
ccls -index ~/Dev/Linux -init='{"clang":{"excludeArgs":[
"-falign-jumps=1","-falign-loops=1","-fconserve-stack","-fmerge-constants","-fno-code-hoisting","-fno-schedule-insns","-fno-sched-pressure","-fno-var-tracking-assignments","-fsched-pressure",
"-mhard-float","-mindirect-branch-register","-mindirect-branch=thunk-inline","-mpreferred-stack-boundary=2","-mpreferred-stack-boundary=3","-mpreferred-stack-boundary=4","-mrecord-mcount","-mindirect-branch=thunk-extern","-mno-fp-ret-in-387","-mskip-rax-setup",
"--param=allow-store-data-races=0","-Wa,arch/x86/kernel/macros.s","-Wa,-"
], "extraArgs":["--gcc-toolchain=/usr"]}}'Note: for options controlling individual optimization behaviors, there is a large probability that they may not make sense for Clang since the two compilers' internals are so different. Comment Actions If this is the case, can we at least add a CMake option to disable LLVM from enabling this option against the user's will? As it stands https://reviews.llvm.org/rG47f5c54f997a59bb2c65abe6b8b811f6e7553456 represents a significant regression in usability. As I understand, the previous patch only had an issue with LTO builds, so it should be perfectly reasonable for users to at least disable this at the LLVM level if they do not with the LLVM build to insert an incompatible flag into their compilation database. Comment Actions Hi, I found this review request and I just want to comment that I find it strange that it was rejected. @MaskRay I understand that using a compile_commands.json configured for gcc with clang-based tools is not a supported use case, but still the clang driver was explicitly designed to emulate gcc: "The clang tool is the compiler driver and front-end, which is designed to be a drop-in replacement for the gcc command" and "The 'clang' driver is designed to work as closely to GCC as possible to maximize portability." are quotes from https://clang.llvm.org/get_started.html In my view, the main objection to "accept and ignore" a GCC option is when the option provides some guarantees that clang/LLVM cannot uphold. For example, ignoring -fno-strict-aliasing would be dangerous if you actually carry out type-based aliasing optimizations, because programs that compile with it likely contain violations of the strict aliasing rules. It seems that -fno-lifetime-dse similarly intends to allow violating a language rule. I'm not aware if clang/LLVM contains optimization that exploit this language rule (since the option appears in the context of the LLVM code base itself, and because compiling this code base with clang itself is well tested in many configurations, I suspect not), but if it does (now or in the future), ignoring this option is dangerous. Regards, Comment Actions Clang does emulate a lot of options, but this does not mean we will add every option GCC supports.
We want that the project and users learn to remove unsupported options. Nowadays, clang_ignored_gcc_optimization_f_Group should probably not be used anymore.
I think it's possible that LLVM in the future make take advantage of the similar idea behind GCC's -flifetime-dse, but the semantics may or may not be exactly the same. MemorySanitizer's error checking is a bit like -flifetime-dse (https://github.com/llvm/llvm-project/issues/24952). |