[llvm-dev] Canonical way to handle zero registers?

[Sean Silva via llvm-dev]

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>