[llvm] [X86] combineCMov - fold CMOV(LOAD(PTR0),LOAD(PTR1)) -> LOAD(CMOV(PTR0,PTR1)) (PR #182084)

[Razvan Lupusoru via llvm-commits]

razvanlupusoru wrote:

@RKSimon I don't think Slava was implying there was a new "R_X86_64_REX_GOTPCRELX change". The point was that the failures appear to be triggered by an existing GNU ld relaxation behavior (enabled by default; -Wl,-no-relax avoids it), and that this new LLVM change is now generating a pattern that miscompiles at link-time with a production linker (GNU ld 2.38).

So even if the root cause is a GNU ld relaxation bug, this is still a regression for deployed configuration: flang -O2 -Wl,-no-pie produces a crashing executable unless we disable relaxation. We're seeing widespread failures due to this change, and it looks like others are seeing failures as well (e.g. https://github.com/ROCm/llvm-project/commit/74128c7c9c609a6348af27fb5a167e4a62c194ce).

Given that, I think we should revert this LLVM change to restore correctness, and then give you time to investigate a mitigation to avoid conflicts with the linker optimization. Does this sound reasonable?

https://github.com/llvm/llvm-project/pull/182084