<div dir="ltr"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Reshabh, and congratulations on being selected for GSoC. I haven't<br>looked at supporting larger than native-width pointers on a target<br>before. I'd thought that AVR might be relevant (given it uses 16-bit<br>pointers but has 8-bit GPRs). See the description here<br><<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html</a>>.<br></blockquote><div><br></div><div>Many thanks Alex, the AVR backend looks like a very promising reference. I'm planning to follow their approach. </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 10, 2019 at 9:33 PM Alex Bradbury <<a href="mailto:asb@lowrisc.org" target="_blank">asb@lowrisc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 5 Jun 2019 at 08:41, Reshabh Sharma via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hello everyone,<br>
><br>
> 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 (<a href="http://bjump.org/manycore" rel="noreferrer" target="_blank">bjump.org/manycore</a>).<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> 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?<br>
><br>
> We would be happy to hear your views and suggestions on this :)<br>
<br>
Hi Reshabh, and congratulations on being selected for GSoC. I haven't<br>
looked at supporting larger than native-width pointers on a target<br>
before. I'd thought that AVR might be relevant (given it uses 16-bit<br>
pointers but has 8-bit GPRs). See the description here<br>
<<a href="http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/llvm-dev/2019-January/129089.html</a>>.<br>
CCing Dylan McKay in case he has any thoughts.<br>
<br>
Best,<br>
<br>
Alex<br>
</blockquote></div>