[LLVMdev] C as used/implemented in practice: analysis of responses

Chris Lattner clattner at apple.com
Thu Jul 9 22:02:24 PDT 2015


On Jul 7, 2015, at 7:18 PM, Sean Silva <chisophugis at gmail.com> wrote:
> 
> 
> You can easily get a 2x or more speedup due to auto-vectorization if you can assume -fstrict-aliasing.  Of course usually you wouldn’t write this code, you’d get this because doLoopThing is a template, and N is passed in as a reference.
> 
> 
> You're absolutely right that it's complicated, but I don't think this is the best example.
> 
> The 2x speedup optimizations you're talking about can be done even without strict aliasing or signed overflow. You just have to emit runtime checks. It's analogous to emitting the "remainder" loop when doing autovectorization. Imagine if the standard made it undefined for a loop over an array of more than 4 floats to not be suitable for vectorization: sure, that would be nice and make the vectorizer's life easier, but we can mostly get the "big bang" speedup without it, in the sense that not having the standard say it is UB probably results in closer to 2% "slowdown" in the aggregate across all these loops (factoring in icache, etc.) than 2x.

As Hal points out, this is only true for the simplest cases.  By the same line of argument, the compiler should only “use UB information” when it knows it will get a “major speedup”.  This approach would at least introduce the risk of UB only when there is some benefit being had.

That, unfortunately, is an extremely difficult problem.  Except in simple cases, it is very hard in a multi-layered compiler to know what speedup result some (e.g.) alias query returning NoAlis instead of MayAlias will result in a client.

-Chris


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


More information about the llvm-dev mailing list