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

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>

On Thu, 11 Jul 2019 at 18:23, Reshabh Sharma <reshabhsh at gmail.com>
wrote:
> 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?
Yes, that's right. The concept is called a "code model". You can
play
with -mcmodel=small or large to see how it affects codegen on x86 and
AArch64. Both have "small" as the default, which allows all globals
(and other related things like vtables, literal strings etc) to be
addressed pretty much as if in 32-bit mode.
>> 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?
That's mostly making sure 64-bit pointers don't get truncated and get
applied correctly (they can still come from something like mmap, or
even malloc). But you still get to choose layout constraints if you
want.

I think the main caveat is that JITs often require support for "large"
(i.e. the full 64-bit addressing you've been implementing up to now),
precisely because they might be handed large pointers by mmap.

BTW, since you're running under 32-bit RISC-V, how do you actually
plan to load from a 64-bit pointer? Isn't the hardware just missing?

Cheers.

Tim.

On Thu, Jul 11, 2019 at 11:13 PM Tim Northover <t.p.northover at
gmail.com>
wrote:
> On Thu, 11 Jul 2019 at 18:23, Reshabh Sharma <reshabhsh at gmail.com>
wrote:
> > 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?
>
> Yes, that's right. The concept is called a "code model". You
can play
> with -mcmodel=small or large to see how it affects codegen on x86 and
> AArch64. Both have "small" as the default, which allows all
globals
> (and other related things like vtables, literal strings etc) to be
> addressed pretty much as if in 32-bit mode.
>
Thanks, that's cool.
>
> >> 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?
>
> That's mostly making sure 64-bit pointers don't get truncated and
get
> applied correctly (they can still come from something like mmap, or
> even malloc). But you still get to choose layout constraints if you
> want.
>
> I think the main caveat is that JITs often require support for
"large"
> (i.e. the full 64-bit addressing you've been implementing up to now),
> precisely because they might be handed large pointers by mmap.
>
> BTW, since you're running under 32-bit RISC-V, how do you actually
> plan to load from a 64-bit pointer? Isn't the hardware just missing?
>
We are working on a RV32 GPU ISA for an open source RISCV based GPGPU (
http://bjump.org/manycore/). So I can easily get the minimal required
hardware support for such features :)

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