[llvm] r279804 - Replace subregister uses when processing tied operands
Krzysztof Parzyszek via llvm-commits
llvm-commits at lists.llvm.org
Tue Aug 30 08:53:27 PDT 2016
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
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.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
More information about the llvm-commits