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

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 :)

Many thanks,
Reshabh Sharma
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190605/833b5528/attachment.html>

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

>
> 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>