[PATCH] D150930: [Driver] Accept and ignore -fno-lifetime-dse argument

Thu Nov 16 11:11:27 PST 2023

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