Displaying 3 results from an estimated 3 matches for "mo_lo32_lo".
Did you mean:
mo_lo32_hi
2019 Jul 11
2
Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
...abh 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 pre...
2019 Jul 11
2
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
2019 Jul 11
2
Manipulating global address inside GlobalAddress SDNode in (RISCV) LLVM backend
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.
>
> By the way, I probably should have said sooner but most targets with
> 64-bit pointers don't (at least in the default mode) materialize...