[llvm-dev] Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend

[Reshabh Sharma via llvm-dev]

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>