llvm dev - Dec 2017 - Canonical way to handle zero registers?

On Dec 27, 2017 2:00 PM, "Matt Arsenault" <arsenm2 at gmail.com>
wrote:


> On Dec 26, 2017, at 18:42, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
> Thanks! That looks like a winning approach.
>
> I swear I grepped around for ISD::Constant but for some reason never
found this code. I think maybe I was searching for ISD::Constant with
setOperationAction, which in hindsight was narrowing down my search to just
lowering, which is exactly what I didn't want! (I was looking for other
approaches). I also tried looking in depth at PowerPC but it looks like it
doesn't use this approach either.
>
> -- Sean Silva
What’s the reason for trying to handle this in SelectionDAG at all? I would
just materialize zero like any other constant, and treat replacing that
with the zero register as an immediate folding optimization (e.g.
FoldImmediate or another peephole pass)


I thought about doing that, but I wasn't sure I could make it work.

The issue is that the hardwired registers are actually the only way to
write immediates of this register class (the registers are very small,
obviously). I've been phrasing this as integer 0 (and -1) to keep the
discussion closer to other architectures, but the fact that these hardwired
registers are the only way to reference immediates of this register class
is one important difference.

One thing I've been curious about is how immediates interact with register
classes. Could we use ordinary immediate MachineOperand's (of the
appropriate bit width) and just print the immediate MO's of this register
class as the corresponding hardwired register? Does MIR have any
constraints on using an immediate MO instead of a register?

-- Sean Silva


-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171228/2df4dabc/attachment.html>

On 12/28/2017 8:02 PM, Sean Silva via llvm-dev wrote:
> One thing I've been curious about is how immediates interact with 
> register classes. Could we use ordinary immediate MachineOperand's (of 
> the appropriate bit width) and just print the immediate MO's of this 
> register class as the corresponding hardwired register? Does MIR have 
> any constraints on using an immediate MO instead of a register?
You can construct an instruction that has an immediate operand in place 
of a register, but that won't work well.  For one, the MachineVerifier 
will complain about having an invalid operand, plus any code that tries 
to use operand information for that instruction may end up "surprised"
to see an immediate where a register was expected.

There is an assumption in MIR that physical registers should not be used 
as explicit operands before RA, except in COPY instructions, so the most 
"canonical" way of having it in MIR is something like
   %vreg2 = COPY %PHYSICAL_ZERO
   ... = %vreg2

If using these special registers is the only way to put an immediate in 
a register of that class, then that suggests that immediates are 
generally not "legal" for that register class (except for the special 
cases). It means that after legalization, the selection DAG should not 
contain immediates of the type associated with that register class 
except for the values that are explicitly allowed.  You could then 
simply write a custom selection code for ISD::Constant, and turn it into 
"CopyFromReg".

-Krzysztof

> On Dec 29, 2017, at 11:34, Krzysztof Parzyszek via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> You can construct an instruction that has an immediate operand in place of
a register, but that won't work well.  For one, the MachineVerifier will
complain about having an invalid operand, plus any code that tries to use
operand information for that instruction may end up "surprised" to see
an immediate where a register was expected.
You could do this, but you would have to define a custom operand type with
custom verification for the allowed operand types. This is how AMDGPU handles
most operands which can be registers or specific immediates

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171229/9d98a2c0/attachment.html>

Thanks! That's exactly the explanation I was looking for!

On Dec 29, 2017 8:34 AM, "Krzysztof Parzyszek via llvm-dev" <
llvm-dev at lists.llvm.org> wrote:
> On 12/28/2017 8:02 PM, Sean Silva via llvm-dev wrote:
>
>> One thing I've been curious about is how immediates interact with
>> register classes. Could we use ordinary immediate MachineOperand's
(of the
>> appropriate bit width) and just print the immediate MO's of this
register
>> class as the corresponding hardwired register? Does MIR have any
>> constraints on using an immediate MO instead of a register?
>>
>
> You can construct an instruction that has an immediate operand in place of
> a register, but that won't work well.  For one, the MachineVerifier
will
> complain about having an invalid operand, plus any code that tries to use
> operand information for that instruction may end up "surprised"
to see an
> immediate where a register was expected.
>
> There is an assumption in MIR that physical registers should not be used
> as explicit operands before RA, except in COPY instructions, so the most
> "canonical" way of having it in MIR is something like
>   %vreg2 = COPY %PHYSICAL_ZERO
>   ... = %vreg2
>
> If using these special registers is the only way to put an immediate in a
> register of that class, then that suggests that immediates are generally
> not "legal" for that register class (except for the special
cases). It
> means that after legalization, the selection DAG should not contain
> immediates of the type associated with that register class except for the
> values that are explicitly allowed.  You could then simply write a custom
> selection code for ISD::Constant, and turn it into "CopyFromReg".
>
> -Krzysztof
> _______________________________________________
> 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/20171229/8b625e06/attachment.html>