[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