[RISCV] Large code model places integer/FP constant pool entries in .rodata and uses PC-relative accesses.

[topperc]

There's no guarantee that .rodata is anywhere near .text in the large code model.

If I'm reading gcc's generated code right, they place constant pool entries the .text section for the large code model.

CC: @jrtc27 @kito-cheng @lenary @tclin914

[llvmbot]

@llvm/issue-subscribers-backend-risc-v

Author: Craig Topper (topperc)

There's no guarantee that .rodata is anywhere near .text in the large code model.

If I'm reading gcc's generated code right, they place constant pool entries the .text section for the large code model.

CC: @jrtc27 @kito-cheng @lenary @tclin914

[lenary]

Presumably what's happening is that the integer/fp constant is getting placed very far away, but then there is a literal pool added close to the function to materialise the address of that constant? If we're not even doing this, then the large code model must be broken entirely.

I agree we should be able to put the integer/fp constant into where we're currently we should be putting its address, even if this duplicates integer/fp constant entries in the whole binary.

[topperc]

Presumably what's happening is that the integer/fp constant is getting placed very far away, but then there is a literal pool added close to the function to materialise the address of that constant? If we're not even doing this, then the large code model must be broken entirely.

We're not doing that.

I'm not sure we're even creating local constant pools close to the function for global address. Seems like we're just putting the constant pools containing the address into .data.rel.ro.