Cool! Looks like we do lots of provably unnecessary alignment checks. :) 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141125/a69806ef/attachment.html>
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 <mailto: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 <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 <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 <http://blog.regehr.org/extra_files/souper-nov-14/bysize.html> > > > John > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <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/a1732b84/attachment.html>
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>
On 25 Nov 2014, at 17:58, Reid Kleckner <rnk at google.com> wrote:> Cool! Looks like we do lots of provably unnecessary alignment checks. :)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