MaskRay added a comment. In D150930#4656909 <https://reviews.llvm.org/D150930#4656909>, @brunodf wrote:
> 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 that regard, `clang_ignored_gcc_optimization_f_Group` is logical and it > includes many options that you cite like `-falign-jumps=`, `-falign-loops=`, > `-fmerge-constants`, `-fschedule-insns`, etc. > Sure, more projects support clang directly now, but I was not aware there is > a change in this policy, or that there is a "stop" on adding more options (in > that case, it would be consistent that the documentation is adapted to say > that clang is only drop-in compatible with some historic version of gcc). Clang does emulate a lot of options, but this does not mean we will add every option GCC supports. I think this sentence in my previous reply applies: > For a useful option, we consider implementing it, but I think the bar is > higher than appeasing such unsupported use cases 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. > 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. 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. And we may choose to implement `-fno-lifetime-dse` or not. MemorySanitizer's error checking is a bit like `-flifetime-dse` (https://github.com/llvm/llvm-project/issues/24952). If we implement `-flifetime-dse`, we may need to think about its interaction with MemorySanitizer, which brings more complexity. Right now, the justification for adding an ignored option is not significant enough. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150930/new/ https://reviews.llvm.org/D150930 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
