[llvm-dev] Support 64-bit pointers in open source RV32 GPU ISA using register pairs and address space ID’s

[Reshabh Sharma via llvm-dev]

>
> Hi Reshabh, and congratulations on being selected for GSoC. I haven't
> looked at supporting larger than native-width pointers on a target
> before. I'd thought that AVR might be relevant (given it uses 16-bit
> pointers but has 8-bit GPRs). See the description here
> <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>.
>

Many thanks Alex, the AVR backend looks like a very promising reference.
I'm planning to follow their approach.

On Mon, Jun 10, 2019 at 9:33 PM Alex Bradbury <asb at lowrisc.org> wrote:

> On Wed, 5 Jun 2019 at 08:41, Reshabh Sharma via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hello everyone,
> >
> > We are working on extending RISC-V LLVM backend which will help us to
> achieve the goal of improving programmability in the second generation
> design of our open source RISC-V manycore processor (bjump.org/manycore).
> >
> > We started with supporting 64 bit pointers in RISCV 32 bit backend using
> address spaces and register pairs. We aim to support 64 bit pointers in
> address space 1 using a pair of i32 registers. The 64 bit address will be
> stored in two i32 registers and we will add custom load/store instructions
> to concat the data from the two registers for getting the 64 bit address at
> the hardware level.
> >
> > We started with updating the data layout string to
> "e-m:e-p:32:32-p1:64:64-i64:64-n32-S128" and we are stuck in the
> legalization phase.
> >
> > Example for node "i64 = TargetGlobalAddress<[3 x i64] addrspace(1)*
> @foo> 0", it does not automatically expand the i64 result into two i32. We
> tried to convert i64 into v2i32 so that it can pass the legalizer but that
> does not seem to work well. Is there any simpler way to handle this?
> >
> > We would be happy to hear your views and suggestions on this :)
>
> Hi Reshabh, and congratulations on being selected for GSoC. I haven't
> looked at supporting larger than native-width pointers on a target
> before. I'd thought that AVR might be relevant (given it uses 16-bit
> pointers but has 8-bit GPRs). See the description here
> <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html>.
> CCing Dylan McKay in case he has any thoughts.
>
> Best,
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190611/7d17dd42/attachment.html>