llvm dev - Nov 2014 - [LLVMdev] new set of superoptimizer results

I strongly suspect pointer union and pointer int pair style classes are the
source of these... But perhaps I'm wrong
 On Nov 26, 2014 9:29 AM, "Michael Zolotukhin" <mzolotukhin at
apple.com>
wrote:
> John,
>
> That’s a great post and really interesting data, thank you!
>
> On Nov 25, 2014, at 9:58 AM, Reid Kleckner <rnk at google.com> wrote:
>
> Cool! Looks like we do lots of provably unnecessary alignment checks. :)
>
> 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
>
>
> On Tue, Nov 25, 2014 at 9:03 AM, John Regehr <regehr at cs.utah.edu>
wrote:
>
>> 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
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141126/666e1449/attachment.html>

> 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

> On Nov 27, 2014, at 7:24 AM, John Regehr <regehr at cs.utah.edu>
wrote:
> 
>> 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
> 
> John