llvm dev - Jul 2019 - Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend

On Thu, Jul 11, 2019 at 10:21 PM Tim Northover <t.p.northover at
gmail.com>
wrote:
> On Thu, 11 Jul 2019 at 17:16, Reshabh Sharma <reshabhsh at gmail.com>
wrote:
> > We thought LUI and ADDI pair will be good to store the values in a i32
> register.
>
> With you so far, I think. To be explicit, to materialize a full 64-bit
> pointer you'd need 4 instructions:
>
>     lui rLO32, addr:MO_LO32_LO
>     addi rLO32, rLO32, addr:MO_LO32_HI
>     lui rHI32, addr:MO_HI32_LO
>     addi rHI32, rLO32, addr:MO_LO32_HI
>
> or some variation for PIC etc.
>
> >  If we could transform GlobalAddress<0xHighLow> directly to
> GlobalAddress<0xLow>, we could use the present RISCVII::MO_HI and
MO_LO as
> they only exact the 32 high bits. What do you think?
>
> I still recommend against reusing GlobalAddress as-is with an i32
> type, but that's probably a minor detail. The only way I can see to
> reuse the existing modifiers unambiguously would be to modify the
> above sequence to:
>
>     lui rLO32, addr:MO_LO
>     addi rLO32, rLO32, addr:MO_LO
>     lui rHI32, addr:MO_HI
>     addi rHI32, rLO32, addr:MO_HI
>
> It kind of works, but personally I think it's stretching the
> understood semantics of MO_LO and MO_HI too far -- I'd add new ones if
> it was me. But I'm not an active RISC-V maintainer so take my opinions
> with a grain of salt.
>
Ah now I could see it more clearly. I was not sure that should I add them
(MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for now we
are going with this. I implemented them today and they seem to work well.

Many thanks,
Reshabh

> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/7bcdef76/attachment.html>

On Thu, 11 Jul 2019 at 18:03, Reshabh Sharma <reshabhsh at gmail.com>
wrote:
> Ah now I could see it more clearly. I was not sure that should I add them
(MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for now we are
going with this. I implemented them today and they seem to work well.
By the way, I probably should have said sooner but most targets with
64-bit pointers don't (at least in the default mode) materialize
64-bit absolute pointers as we've been discussing.

x86 requires all global variables live with code in the low 2GB of
memory, which allows direct use of %rip-relative addressing-modes.
AArch64 requires all globals & code to be within 4GB of each other at
an arbitrary location in memory.

If you adopted similar constraints for RISC-V you could probably use
the existing code virtually unchanged.

Cheers.

Tim.

On Thu, Jul 11, 2019 at 10:42 PM Tim Northover <t.p.northover at
gmail.com>
wrote:
> On Thu, 11 Jul 2019 at 18:03, Reshabh Sharma <reshabhsh at gmail.com>
wrote:
> > Ah now I could see it more clearly. I was not sure that should I add
> them (MO_LO32_LO and MO_LO32_HI), btw this was backup plan. Probably for
> now we are going with this. I implemented them today and they seem to work
> well.
>
> By the way, I probably should have said sooner but most targets with
> 64-bit pointers don't (at least in the default mode) materialize
> 64-bit absolute pointers as we've been discussing.
>
> x86 requires all global variables live with code in the low 2GB of
> memory, which allows direct use of %rip-relative addressing-modes.
> AArch64 requires all globals & code to be within 4GB of each other at
> an arbitrary location in memory.
>
Correct me if I understood it wrong, keeping global variables at some
arbitrary location in memory with a limit of 4GB so that they can be
addressed in 32 bits?

> If you adopted similar constraints for RISC-V you could probably use
> the existing code virtually unchanged.
>
We are trying to support 4GB+ memory in address space 1 using 64 bit
pointers in that address space, I guess then this might not apply? What do
you think?

Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/e76afdbf/attachment-0001.html>