[PATCH] Hexagon Register Cleanup

[Andrew Trick]

On May 14, 2013, at 9:27 AM, Krzysztof Parzyszek <kparzysz at codeaurora.org> wrote:

> On 5/13/2013 7:58 PM, Andrew Trick wrote:
>> 
>> 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.
> 
> Well, this was actually a part of the problem.  We do use register scavenger, and it would complain in cases like
>  R0 = ...
>  R1 = ...
>  ... = D0
> The pass was meant to handle the problem and not break the scavenger.

Eventually we might be able to make the scavenger work, conservatively, without implicit def/use operands by tracking register units instead of register names.

>> 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.
> 
> I considered various options before I resorted to this, but none of them would work.  There is no way in LLVM to say "consider D0 defined at this point" without making this declaration a definition.  Ideally (for us), we would have something like:
>  R0 = ...
>  R1 = ...
>  CONSIDER_DEFINED D0  // An informational directive, not a def.
>  ... = D0
> 
> There was nothing like that available.  For us "undef" doesn't really matter, so I hijacked it for our purposes.  I never meant for it to be affecting anyone else but Hexagon.  I had to change the DAG building, but the changes only take effect when a flag is set, which only happens on Hexagon.

I completely understand. The point is, this isn’t something we want on trunk if it can be avoided. I won’t complain about any workaround you want to add in Target/Hexagon, and if you really need a hook into ScheduleInstrs that can be arranged. However, we run into this situation a lot, and the first tactic should be for the target to postprocess the DAG so we aren’t embedding target-specific workarounds in the generic DAG builder.

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