llvm dev - Apr 2012 - [LLVMdev] InstCombine adds bit masks, confuses self, others

On Apr 16, 2012, at 3:30 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> Does sinking these into the DAGCombine layer help? How much does it break?
I tried disabling just the InstCombine transforms that hide shl instructions
behind bitmasks. Even though DAGCombine has the same transforms, it causes some
pretty bad regressions:

External/SPEC/CINT95/147_vortex/147_vortex                                  
0.294   0.322   +9.6%  +40mB
MultiSource/Benchmarks/Olden/tsp/tsp                                        
0.680   0.748   +9.9%  +41mB
SingleSource/Benchmarks/Shootout-C++/except                                 
0.116   0.128  +10.8%  +45mB
SingleSource/Benchmarks/Shootout/strcat                                     
0.102   0.113  +11.1%  +46mB
SingleSource/Benchmarks/Shootout-C++/hash                                   
0.455   0.507  +11.4%  +47mB
External/Povray/povray                                                      
2.015   2.246  +11.5%  +47mB
External/SPEC/CINT2000/255_vortex/255_vortex                                
1.814   2.044  +12.7%  +52mB
SingleSource/Benchmarks/Shootout-C++/heapsort                               
1.871   2.132  +13.9%  +57mB
SingleSource/Benchmarks/Shootout-C++/ary3                                   
1.087   1.264  +16.3%  +65mB
MultiSource/Benchmarks/SciMark2-C/scimark2                                 
27.491  23.596  -14.2%  -66mB
MultiSource/Benchmarks/Olden/bisort/bisort                                  
0.360   0.428  +19.0%  +75mB
MultiSource/Benchmarks/Olden/bh/bh                                          
1.074   1.287  +19.9%  +79mB

(Running on Sandy Bridge, x86-64)

I'll try to figure out why.

/jakob

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

On Wed, Apr 18, 2012 at 12:22 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk>wrote:
> I tried disabling just the InstCombine transforms that hide shl
> instructions behind bitmasks. Even though DAGCombine has the same
> transforms, it causes some pretty bad regressions:
>
I wonder about your idea of still combining most of the shifts, but leaving
the last bits uncombined... Certainly the combining effects seem
particularly important to capture because we'll only look through a finite
number of shifts to determine demanded bits, etc.

I would expect that, even with the fix, demanded bits might need adjusting
to cope with the pattern.

But this is all theorizing. =] The actually regressions will likely tell
more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120418/6d713c36/attachment.html>

On Apr 17, 2012, at 3:29 PM, Chandler Carruth wrote:
> On Wed, Apr 18, 2012 at 12:22 AM, Jakob Stoklund Olesen <stoklund at
2pi.dk> wrote:
> I tried disabling just the InstCombine transforms that hide shl
instructions behind bitmasks. Even though DAGCombine has the same transforms, it
causes some pretty bad regressions:
> 
> I wonder about your idea of still combining most of the shifts, but leaving
the last bits uncombined... Certainly the combining effects seem particularly
important to capture because we'll only look through a finite number of
shifts to determine demanded bits, etc.
Yes, the idea is to only preserve shl instructions because of their
arithmetic/logical duality. I'll keep folding ashr/lshr.

These transformations all still run:

  X << C1 >> C2 --> X << (C1-C2) & Mask
  X << C1 >> C2 --> X >> (C2-C1) & Mask
  X << C1 << C2 --> X << (C1+C2)
  X >> C1 >> C2 --> X >> (C1+C2)

I also allow folding of exact right shifts:

  X >>exact C1 <<nuw C2 --> X <<nuw (C2-C1)
  X >>exact C1 << C2 --> X >>exact (C1-C2)

Since a bit mask isn't needed, scalar evolution should be able to reason
about this.

Long chains of shifts should still be collapsed this way.
> But this is all theorizing. =] The actually regressions will likely tell
more.
Yeah, all of the regressions I posted actually had identical assembly. I'll
try measuring again while holding my breath.

/jakob

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