llvm dev - Jul 2019 - 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>

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.

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>