[PATCH] Teach rematerialiser more about subregs

Jakob Stoklund Olesen jolesen at apple.com
Wed May 29 11:06:29 PDT 2013


On May 29, 2013, at 8:23 AM, Tim Northover <tnorthover at apple.com> wrote:

> Hi,
> 
> The attached patch should allow the rematerializer (during register coalescing) to handle sub-register indices more intelligently. Previously CodeGen could produce something like:
> 
> %vreg1:sub_32 = MOVZwii whatever
> %vreg2 = COPY %vreg1
> 
> (where both registers have class GPR64). This ought to be a candidate for rematerialisation, producing
> 
> %vreg2:sub_32 = MOVZwii whatever
> 
> however, the code at the moment doesn't attempt anything since %vreg2 itself isn't an appropriate operand for MOVZwii (which takes a GPR32).

I think you probably need to make sure that the DefMI isn’t an partial register update:

  %vreg1:sub_32<def> = MOVZwii whatever

You probably can’t rematerialize that (or it wouldn’t help anyway). You need the undef flag:

  %vreg1:sub_32<def,read-undef> = MOVZwii whatever

It’s not really clear if there is a check for that hidden somewhere.

+      assert(CP.getNewRC() && "Invalid unified register-class for remat");
+
+      // If the COPY was cross-lane then we can't just replace it with the
+      // defining-instruction.
+      if (TRI->composeSubRegIndices(DstIdx, DstOperand.getSubReg()) !=
+          TRI->composeSubRegIndices(SrcIdx, CopySrcOperand.getSubReg()))

Are these checks necessary? It looks like CoalescerPair::setRegisters() will never return true if these checks are not satisfied.

Otherwise, looks good!

/jakob





More information about the llvm-commits mailing list