MachineOperand: Subreg defines and the Undef flag

Hi,

This question relates to the undef flag in the context of sub-register def
operands.

1) Firstly, the documentation (comments in the source code) says that in a
sub-register def operand, the "IsUndef" flag refers to the part of the
register that is not written.
2) Further, the documentation about readsReg() states that a sub-register
def implicitly reads the other parts of the register being redefined unless
the <undef> flag is set.

Now, I am writing a pass the splits the following sequence of MIs

MI1:: A<def> = 0xFFFFFFFF ; A is a 64bit super reg.
MI2:: B<def> = C & A ; C and B are also 64bit super regs.

Into
NewMI_1:: B:lo_sub_reg<def> = COPY C:lo_sub_reg.
NewMI_2:: B:hi_sub_reg<def> = 0

The question is how should I be setting up the <undef> flags on the def
operands of NewMI_1 and 2 ? Should I set the <undef> flag only on NewMI_1
because in NewMI_2 lo_sub_reg has already been defined by NewMI_1?
Or should the <undef> flags be set in both as per 2 above ?

TIA,
Pranav

Qualcomm Innovation Center, (QuIC) is a member of the Code Aurora Forum.

The <undef> flag goes on NewMI_1 because the virtual register B isn't live before that instruction.

But you probably shouldn't be doing this yourself. Your NewMI code isn't in SSA form because B has multiple definitions. Just use a REG_SEQUENCE instruction, and let the register allocator do the transformation for you.

/jakob

Hi Jakob,

Thanks for your reply.

The <undef> flag goes on NewMI_1 because the virtual register B isn't live
before that instruction.

But you probably shouldn't be doing this yourself. Your NewMI code isn't

in

SSA form because B has multiple definitions. Just use a REG_SEQUENCE
instruction, and let the register allocator do the transformation for you.

Aaargh. So you mean something like this ?

New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2
are 32 bit virt. regs.
New_MI_2:: Vreg2 = COPY C:lo_sub_reg.
New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B is a
64 bit virt reg.

TIA,
Pranav

Yes.

For this particular case, you can also use INSERT_SUBREG. That might be simpler.

/jakob

Hi Jakob,

New_MI_1:: Vreg1 = 0 ; Vreg1 and Vreg2
are 32 bit virt. regs.
New_MI_2:: Vreg2 = COPY C:lo_sub_reg.
New_MI_3:: B= REG_SEQUENCE<Vreg1, hi_sub_reg, Vreg2, lo_sub_reg> ; B
is a
64 bit virt reg.

I used this approach and it worked find until I hit, what I believe is, a
bug in the register coalescer.
When the register coalescer cannot trivially coalesce a copy, say C, it
calls AdjustCopiesBackFrom. In this function, we try to see if have this
situation.

A3 = B0
   .....
   .....
B1 = A3 <--The copy C

And if so, we check if we can merge the two ranges of B into a single range.
However, this is not safe if A3 is a subreg define while A3 is not a subreg
use.
For instance, consider this code (part of a single block loop).

MI1:: %vreg7:subreg_loreg<def,undef>, %vreg30<def> = POST_LDriuh %vreg30,
2, // Post Inc. Load. Vreg7 is a 64bit reg.
MI2:: %vreg7:subreg_hireg<def> = COPY %vreg32:subreg_hireg<kill>
// This is the A3 = B0 above.
MI3:: %vreg31<def> = ADD_rr %vreg31<kill>, %vreg32:subreg_loreg<kill>
// Use the lo subreg that was setup in MI1:
....
....
MI4:: %vreg32<def> = COPY %vreg7; //Not trivial
because 7 is not killed. This is the Copy C i.e. B1=A3.
....
MI5:: Conditional jump back to start of the block.

The coalesce coalesces the copy withouth realizing that the instruction that
defined the source of the copy was a copy instruction that only copied a
subreg not the whole register.
In the event, we lose the lower subreg.

Let me know If I am missing something.

Pranav

Qualcomm Innovation Center, (QuIC) is a member of the Code Aurora Forum.

That sounds like a bug, probably adjustCopiesBackFrom needs to check ACopyMI->isFullCopy().

Do you have a test case for this?

/jakob

That sounds like a bug, probably adjustCopiesBackFrom needs to check ACopyMI->isFullCopy().

Do you have a test case for this?

Yes and No. Yes because the example is from a unit testcase that I have. No because it manifests itself only with my half baked pass that I was talking about earlier in this thread.

Pranav

Alright. Even then, patches welcome!

/jakob

Alright. Even then, patches welcome!

/jakob

Certainly.

Pranav