new set of superoptimizer results

I hope there's some useful material in here!

   http://blog.regehr.org/archives/1192

John

Actually, let me save you some time by pointing out the thing that is perhaps immediately useful about our recent work, which is the fact that Souper now supports "optimization profiling".

If you build an LLVM using Souper and then use that LLVM to build SPEC CPU 2006, here are optimizations ranked by dynamic profile count:

   http://blog.regehr.org/extra_files/souper-nov-14/bydprofile.html

In other words, if you implement optimizations near the top of this list, you would be likely to make LLVM compile SPEC CPU 2006 in less time.

Here are the optimizations sorted by static profile count:

   http://blog.regehr.org/extra_files/souper-nov-14/bysprofile.html

Implementing the highly ranked ones would be likely to make the clang binary smaller.

Finally here are the optimizations sorted by size; this is handy because the higher-ranked ones are generally easier to understand:

   http://blog.regehr.org/extra_files/souper-nov-14/bysize.html

John

Cool! Looks like we do lots of provably unnecessary alignment checks. :slight_smile:

John,

That’s a great post and really interesting data, thank you!

Cool! Looks like we do lots of provably unnecessary alignment checks. :slight_smile:

Indeed, but where do these checks come from? As far as I know, right now vectorizer doesn’t generate them, and who else could do that?

Michael

I strongly suspect pointer union and pointer int pair style classes are the source of these… But perhaps I’m wrong

I strongly suspect pointer union and pointer int pair style classes are the source of these...
But perhaps I'm wrong

I'll try to make this guessing game easier by including srclocs in the next set of results.

John

We've hit this with clang and a target that didn't support unaligned accesses. Almost all loads and stores emitted by clang have align 1, rather than the alignment that the C language mandates. There's even a PowerPC test that fails when you fix this in clang, as it depends on the alignment being 1.

David

I strongly suspect pointer union and pointer int pair style classes are the source of these...
But perhaps I'm wrong

Probably that’s it, but my original question was actually about which pass in llvm adds these checks. The stuff you mentioned definitely could be a source of unaligned accesses, but I expected these accesses to remain unaligned across all our passes without any runtime checks.

I'll try to make this guessing game easier by including srclocs in the next set of results.

I’m sure that would be handy.

Michael