search for: reshabh

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

...t; 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>

...) 1. Is Gluing the right approach or there is something better for such use case? 2. If I do something like DAG.getNode(ISD::ADDI, DL, MVT::Glue, LUINode, OtherADDINode). How will it know that the other ADDI node should be glued and not LUI. I seriously feel I'm missing something. Many thanks, Reshabh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/7a7b34d4/attachment.html>

On Thu, Jul 11, 2019 at 10:21 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Thu, 11 Jul 2019 at 17:16, Reshabh Sharma <reshabhsh at gmail.com> wrote: > > We thought LUI and ADDI pair will be good to store the values in a i32 > register. > > With you so far, I think. To be explicit, to materialize a full 64-bit > pointer you'd need 4 instructions: > > lui rLO32, addr:MO_...

...directly to GlobalAddress<0xLow>, we could use the present RISCVII::MO_HI and MO_LO as they only exact the 32 high bits. What do you think? Many thanks for your reply :) On Tue, Jul 9, 2019 at 9:41 PM Tim Northover <t.p.northover at gmail.com> wrote: > On Tue, 9 Jul 2019 at 14:49, Reshabh Sharma via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > For a GlobalAddress node say i64 = GlobalAddress<0xHighLow> we want to > convert it into i32 = GlobalAddress<0xLow>. > > I think you'd have to convert it into a custom RISCVGlobalAddressLow > an...

...o void* will eliminate the need for the conversion to integer using ptrtoint. Removing the ptrtoint from asan instrumentation will boost the performance and will reduce the differences with uninstrumented code. 1. http://lists.llvm.org/pipermail/llvm-dev/2019-January/129095.html Many thanks, Reshabh and Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200710/8d50223c/attachment.html>

...ow>. [The below part is in reference with the RISCV LLVM backend] If there is no direct way to do this, we plan to fall back on a backup plan to convert the GlobalAddress node into the required LUI and ADDI pair but that would require the addition of two new target flag in RISCVII namespace. - Reshabh -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190709/aa10043d/attachment.html>

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