[PATCH] Hexagon Register Cleanup

[Andrew Trick]

On May 13, 2013, at 10:42 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 5/13/2013 12:18 PM, Tom Stellard wrote:
>> 
>> We have the exact same problem for the VLIW4/5 subtargets in R600.
>> Instructions that write to different sub registers of the same super
>> register cannot be scheduled together in the same packet.  Vincent has
>> written a patch to fix this in LLVM core. The latest version that was sent
>> to the list is here:
>> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/141708
>> 
>> But Vincent may be able to point you to a more up to date version.
> 
> The original intent of this patch was that it will eventually be eliminated when the liveness analysis tracks register lanes.  I haven't looked at the patch, but is that what it tries to do?
> 
> We've had this one running for over 6 months and we would need to make sure that we still get the performance with any potential replacement.
> 
> -Krzysztof
> 

The only good machine independent fix for this is to eliminate the
imp-use/imp-def operands. But that has to be done carefully to avoid
breaking existing postRA passes.

A good target-specific workaround for this is to follow Vincent's
approach of modifying the scheduling DAG after it is built.

Vincent's approach worked for vregs and is needed until we track
subreg liveness on vregs. You could implement a similar workaround for
physregs until the imp-def/use operands can be properly removed.

An even quicker hack is for a Hexagon-specific postRA pass to remove
the imp-def/use operands in certain cases. Mostly what will break is
verification, which you could disable. There may be some danger if
you're using the RegScavenger code. I would consult with Jakob before
actually relying on that.

Your current approach misinterprets the meaning of "undef", which is
unsafe to expose to other targets. Undefs can't generally be ignored,
it just conveniently disables verification.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130513/d6818f6b/attachment.html>