[llvm] r279804 - Replace subregister uses when processing tied operands

[Krzysztof Parzyszek via llvm-commits]

On 8/29/2016 6:49 PM, Matt Arsenault wrote:
> I ran into a similar error with AMDGPU I fixed in r278676. For that I
> decided that it doesn't make sense to have an operand with a subregister
> that is tied to a virtual register without one. Before the pass you have:
>     %vreg2<def,tied1> = S2_lsr_i_r_acc %vreg2<tied0>,
> %vreg2:subreg_loreg, 16; IntRegs:%vreg2
>
> I don't think it makes sense to have a tied operand where the full
> register is a different register class. Before the pass you have:
>     %vreg2<def,tied1> = S2_lsr_i_r_acc %vreg0:subreg_loreg<tied0>,
> %vreg0:subreg_loreg, 16; IntRegs:%vreg2 DoubleRegs:%vreg0
>
> The full registers vreg2 and vreg0 are different register classes, and
> you are constraining them to be tied. I think we should make this
> situtation a verifier error. What do you think?

I see your point and it does make sense.  However, this reminds me of 
the situation with PHI instructions: there was a question a while back 
about the restrictions on the input and output registers in a PHI node, 
and the conclusion was that as long as a valid COPY instruction between 
an input and the output can be generated, the PHI instruction is valid.

The situation here is somewhat similar, in the sense that the input and 
the output have to be made identical, and a COPY seems like a valid 
approach to do so. If we were only to require that such a valid COPY 
instruction must exist, it would be consistent with the policy regarding 
PHI nodes.

The problem of picking the optimal register to be the tied operand in 
the two-address pass, of course, remains.

I'm curious about what others think about this.


-Krzysztof

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