Reshabh Sharma via llvm-dev
2019-Jul-11 16:16 UTC
[llvm-dev] Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
> > I don't think there's a real shortage of those, but I confess I'm not > sure why that's related. You'd need a representation for the LUI and > ADDI after instruction selection anyway.Yeah at the end we need a representation for LUI and ADDI. We were trying to break the 64 bit address from GlobalAddress node into two i32 register. We will add custom load/store which will generate the address using values from two registers. We thought LUI and ADDI pair will be good to store the values in a i32 register. If we could transform GlobalAddress<0xHighLow> 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 > and RISCVGlobalAddressHigh pair because the type of GlobalAddress is > fixed to pointer type in TargetSelectionDAG.td (that's not 100% set in > stone, but I wouldn't violate it lightly). And that might well be > functionally equivalent to making an LUI/ADDI pair directly. > > > 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. > > I don't think there's a real shortage of those, but I confess I'm not > sure why that's related. You'd need a representation for the LUI and > ADDI after instruction selection anyway. > > Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/f3a59c30/attachment.html>
Tim Northover via llvm-dev
2019-Jul-11 16:50 UTC
[llvm-dev] Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
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_LO32_LO addi rLO32, rLO32, addr:MO_LO32_HI lui rHI32, addr:MO_HI32_LO addi rHI32, rLO32, addr:MO_LO32_HI or some variation for PIC etc.> If we could transform GlobalAddress<0xHighLow> 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?I still recommend against reusing GlobalAddress as-is with an i32 type, but that's probably a minor detail. The only way I can see to reuse the existing modifiers unambiguously would be to modify the above sequence to: lui rLO32, addr:MO_LO addi rLO32, rLO32, addr:MO_LO lui rHI32, addr:MO_HI addi rHI32, rLO32, addr:MO_HI It kind of works, but personally I think it's stretching the understood semantics of MO_LO and MO_HI too far -- I'd add new ones if it was me. But I'm not an active RISC-V maintainer so take my opinions with a grain of salt. Cheers. Tim.
Reshabh Sharma via llvm-dev
2019-Jul-11 17:03 UTC
[llvm-dev] Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
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_LO32_LO > addi rLO32, rLO32, addr:MO_LO32_HI > lui rHI32, addr:MO_HI32_LO > addi rHI32, rLO32, addr:MO_LO32_HI > > or some variation for PIC etc. > > > If we could transform GlobalAddress<0xHighLow> 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? > > I still recommend against reusing GlobalAddress as-is with an i32 > type, but that's probably a minor detail. The only way I can see to > reuse the existing modifiers unambiguously would be to modify the > above sequence to: > > lui rLO32, addr:MO_LO > addi rLO32, rLO32, addr:MO_LO > lui rHI32, addr:MO_HI > addi rHI32, rLO32, addr:MO_HI > > It kind of works, but personally I think it's stretching the > understood semantics of MO_LO and MO_HI too far -- I'd add new ones if > it was me. But I'm not an active RISC-V maintainer so take my opinions > with a grain of salt. >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. Many thanks, Reshabh> Cheers. > > Tim. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190711/7bcdef76/attachment.html>