llvm dev - Jan 2016 - Expanding a PseudoOp and accessing the DAG

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))
                                                       )
                                      )]>;
}

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.

[as an aside, we've got patterns like:

def : Pat<(XSTGMVINI tglobaladdr:$off),
          (MOVIMMZ_I64 tglobaladdr:$off)>;

]

So, first off, if I wanted to expand that DAG for the RelAddr Node, and I
want something like (the first BuildMI below is pseudo code as I'm not sure
how to accomplish it):

case  XSTG::RelAddr:
    BuildMI(MBB, MI, DL, MI->getOperand(1).DAG...) ???
    BuildMI(MBB, MI, DL, get(XSTG::LOADI32_RI), MI->getOperand(0).getReg())
          .addReg(MI->getOperand(0).getReg())
          .addReg(XSTG::GRP);

Basically, I want to grab the XSTGMVINI that is the second operand to the
XSTGRELADDR node from the psuedo op pattern above and then build an MI
based on that DAG.

The resulting assembly for that DAG would be:
    movimm       rX, %rel(SYMBOL) #offset to SYMBOL
    load             rX, rX, GRP # rX <- mem[rx+GRP]

Where the 'movimm' corresponds to the first BuildMI above (and is the
XSTGMVINI part of the DAG) and the 'load' corresponds to the second
BuildMI
above (I have that one working).

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)

?

Phil
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160113/b972b845/attachment.html>

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

On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
First off, I got this idea from the LLVM Cookbook chapter 8: Writing an
LLVM Backend: Lowering to multiple instructions. (now I'm having my doubts
as to whether this is the right approach)

Let me explain at the assembly level what I'm trying to accomplish.

We're trying to make position independent executables, so we intend to have
a switch like -fPIE. In that case we've designated some registers to be
pointers to various address spaces (and our processor is rather complicated
so there are several address spaces).

Right now,  given a global variable called 'answer' in C we end up with
the
following in the .s file:

  movimm    r1, %rel(answer) # r1 <- offset to 'answer' symbol
  load    r1, r1, 0                     # r1<-mem[r1+0]

This isn't correct because it should be relative to the GRP register if the
PIE mode is chosen, what I'd like to get is either:

  movimm   r1, %rel(answer)
  addI         r1, GRP              # r1 <- r1 + GRP
  load         r1, r1, 0               # r1 <- mem[r1+0]

Or even better:

  movimm   r1, %rel(answer)
  load         r1, r1, GRP      # r1 <- mem[r1+GRP]

What I'm getting at the moment is just this part:

  load        r1, r1, GRP

So the movimm is missing. That's because I've added the Pseudo
instruction
RelAddr and GlobalAddress nodes get converted to RelAddr nodes in
LowerGlobalAddress.... They used to get converted to the MVINI node type
there prior to adding the RelAddr pseudo inst.

It feels like more of this needs to be done in the LowerGlobalAddress
function, but I have no idea how to do it there - you seem to only be able
to get one instruction out of a lowering like that, not multiple
instructions. It also seems like (as you point out) the expansion phase is
too late to be doing it.







>
>
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160113/043d0712/attachment-0001.html>