[llvm-dev] Glue to connect two nodes in LLVM backend

[Tim Northover via llvm-dev]

On Tue, 16 Jul 2019 at 16:24, Reshabh Sharma <reshabhsh at gmail.com> wrote:
>> I would expect the store to take an i64 operand as its address
>> (otherwise, in just what sense are your pointers 64-bit?), and
>> wouldn't expect to need glue at all.
>
> I think we might not need a i64 operand at all (won't they be pain during the legalization as we are working on RV32), as we plan to introduce new load/store like NEW_STORE rd rs1 rs2 (where rs1 has lower 32 bits of 64 bit address and rs2 have higher 32 bits).

That makes sense, and should interact well with the pair/extract idiom
(with some minor annoyance to create those stores taking two sources).

> The use of BUILD_PAIR sounds really promising (I was considering to use a custom wrapper node to do the same thing). I took some time to try to make it work but I guess the legalizer fails after seeing a node with result type i64. I tried to be sure about it but it does not fail when it tries to legalize the BUILD_PAIR node with return type i64 instead it fails when it try to legalize the store node having this as an operand.

> What do you think about it? I think the reason for failure (using BUILD_PAIR) is the i64 result which is not legal so the codegen tries to expand it over store, in which it fails as it does not know how to do that.

If it's not feeding directly into an EXTRACT of the usual i64 ->
(i32,i32) type legalization[*] kind (I think EXTRACT_ELEMENT) then I
would expect failure. So you need to replace your store with the
custom RS1, RS2 variant at the type legalization phase. That's very
early, and might not even have hooks. If you're finding that then the
first DAG-combine phase runs before type legalization, and definitely
can be hooked to replace all stores with your custom node.

Cheers.

Tim.

[*] In case this term isn't familiar, the sequence of DAG phases goes
something like:

Combine 1 -> Type legalization -> Combine 2 -> Legalization -> Selection

After type legalization (for you) *nothing* should have type i64, so
if you need to replace things you have to do it before then. I believe
a part of type legalization will fold BUILD_PAIR/EXTRACT_ELEMENT pairs
to eliminate incidental/trivial i64s.