[llvm] [RISCV] Use proper LLA operand for constant from load (PR #142292)

[Carl Nettelblad via llvm-commits]

cnettel wrote:

> > > Do you have a test case to illustrate the bug you're trying to fix?
> > 
> > 
> > I apologize for not providing one straight away. I only get the behavior when LLA was used for constant pools in a larger project (involving LLVMCPU lowering with IREE), with a quite complex build environment. In fact, I stumbled on this from the very fact that for small test programs, I saw much better optimization than on the full thing, despite the optimization flags being identical.
> > This one-line fix brings those two cases in line with each other, but it is not a minimal reproduction. I'm not familiar enough with the various memory, linkage, and relocations models of RISC-V to know when LLA will be triggered for constant pools. In any such scenario where a late stage KnownBits optimization is possible, the behavior should be triggered.
> > The existing code is buggy in the sense that the return value from GetSupportedConstantPool will always return nullptr in the line affected by the commit. As things stand, Ptr is checked to be a ConstantPoolSDNode, but we only enter that block if Ptr has been established to be a RISCVISD::LLA opcode.
> 
> You can dump the LLVM IR generated by IREE with `--iree-hal-dump-executable-intermediates-to`. If you can reproduce the error with `llc` and those LLVM IR, perhaps you can use `llvm-reduce` to further shrink the reproducer code.

That's the thing. I was already using llc with intermediates when I discovered this, since I wanted to understand why I got strange results for optimizations involving some constants.

I haven't found any settings in llc choosing this codepath, but it's consistently used for the build generating the .ll intermediates in the .o and .s intermediates found in the same directory. In the corresponding cases built within IREE, KnownBits for constants loaded for constant pools were evaluated to all ?.

It's not only a matter of the LLVM IR stream itself, but some other build setting passed on by IREE which I haven't identified. Still, the code generated is valid, it's just that the constant pool strategy used seems to be different. My hypothesis is that my llc build ends up in the codepath using a RISCVISD::ADD_LO/RISCVISD::HI pair, while the IREE build is still abstracting this to RISCVISD::LLA, hitting the bug. If someone has some suggestions on flags to llc that can trigger one or the other, I'll be happy to look into it more.

Again, the actual bug is that the current code assumes the RISCVISD::LLA node itself to also be a ConstantPoolSDNode, which is impossible. The ConstantPoolSDNode is instead an operand to that node. The current code will never provide a non-null result if the constant pool reference is done using RISCVISD::LLA.

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