llvm dev - Oct 2015 - Register Spill Caused by the Reassociation pass

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

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

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>
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151001/cc1715e5/attachment.html>

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>