[llvm-dev] Register Spill Caused by the Reassociation pass

[Gerolf Hoflehner via llvm-dev]

This conflict is with many optimizations incl. copy prop, coalescing, hoisting etc. Each could increase register pressure and with similar impact.  Attempts to control the register pressure locally (within an optimization pass) tend to get hard to tune and maintain. Would it be a better way to describe eg in metadata how to undo an optimization? Optimizations that attempt to reduce pressure like splitting or remat could be hooked up and call an undo routine based on a cost model.

I think there is time to do something longer term. This particular instance can only be an issue under -fast-math.

Cheers
Gerolf

> On Oct 1, 2015, at 9:27 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hi Haicheng,
> 
> We need to prevent the transform if it causes spilling, but I'm not sure yet what mechanism/heuristic we can use to do that.
> Can you file a bug report with a reduced test case?
> 
> Thanks!
> 
> On Thu, Oct 1, 2015 at 9:10 AM, Haicheng Wu <haicheng at codeaurora.com <mailto:haicheng at codeaurora.com>> wrote:
> Hi Sanjay,
> 
>  
> 
> I observed some extra register spills when applying the reassociation pass on spec2006 benchmarks and I would like to listen to your advice. 
> 
>  
> 
> For example, function get_new_point_on_quad() of tria_boundary.cc in spec2006/dealII has a sequences of code like this
> 
>  
> 
> …
> 
> X=a+b
> 
> …
> 
> Y=X+c
> 
> …
> 
> Z=Y+d
> 
> …
> 
>  
> 
> There are many other instructions between these float adds.  The reassociation pass first swaps a and c when checking the second add, and then swaps a and d when checking the third add.  The transformed code looks like
> 
>  
> 
> …
> 
> X=c+b
> 
> …
> 
> Y=X+d
> 
> …
> 
> Z=Y+a
> 
>  
> 
> a is pushed all the way down to the bottom and its live range is much larger now. 
> 
>  
> 
> Best,
> 
>  
> 
> Haicheng
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151002/b2920ff2/attachment.html>