[llvm-dev] Expanding a PseudoOp and accessing the DAG

[Krzysztof Parzyszek via llvm-dev]

On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote:
> I've got this PseudoOp defined:
>
> def SDT_RELADDR       : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>;
> def XSTGRELADDR       : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>;
>
>
> let Constraints = "$dst = $addr" in { //, Uses= [GRP] in {
>    def RelAddr           : XSTGPseudo< (outs GPRC:$dst),
>                                        (ins i64imm:$spoff, i64imm:$addr),
>                                        "! RELADDR $spoff, $dst",
>                                        [(set GPRC:$dst, (XSTGRELADDR
> i64:$spoff,
>
> (i64 (XSTGMVINI i64:$addr))
>                                                         )
>                                        )]>;
> }

Since i64imm is an immediate, the constraint "$dst = $addr" doesn't make 
sense.  The constraint is there to tie the input virtual register to the 
output virtual register, so that they will both be assigned the same 
physical register.


> GlobalAddresses get lowered to RelAddr nodes in our ISelLowering code.
> Now I just need to be able to expand this in our overridden
> expandPostRAPseudo function, however, I'm a bit worried that expansion
> happens too late (after things should already be MI's, it seems). So
> things like patterns that try to  match on that XSTGMVINI would have
> already been matched.

The function expandPostRAPseudo is called after instruction selection, 
after MI-level SSA-based optimizations, after register allocation.  In 
other words, quite late in the entire optimization sequence.  Most of 
the actual optimization work is pretty much done at this point.


> [as an aside, we've got patterns like:
>
> def : Pat<(XSTGMVINI tglobaladdr:$off),
>            (MOVIMMZ_I64 tglobaladdr:$off)>;
>
> ]

I'm not sure if the input will match if you have tglobaladdr in it.  The 
't' means "target", and in this context it means that the argument has 
already been handled by the target and is in a form that does not need 
any further work.  The lowering from globaladdr to tglobaladdr would 
happen after the "bigger" pattern (i.e. the one matching XSTGMVINI) has 
been tried, so this pattern will likely never see this combination of 
arguments.


> So, first off, if I wanted to expand that DAG for the RelAddr Node,

This is where I don't understand what you are trying to do.  The machine 
instructions will be automatically generated and you don't have to build 
them yourself.


> And secondly,
>
> Would this RelAddr DAG:
>
> [(set GPRC:$dst, (XSTGRELADDR i64:$spoff,
>                                                           (i64
> (XSTGMVINI i64:$addr)
> )]
>
> Have been pattern matched (as per the PAT above) such that the XSTGMVINI
> would have been transformed into:
>
> MOVIMMZ_I64 tglobaladdr:$addr)

AFAIK, no.  Global address could be matched by i64 (or an integer type 
that could hold it), but not the other way around.

-Krzysztof


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation