On Tue, May 22, 2012 at 1:52 PM, bearophile <[email protected]>wrote:
> On Reddit they have linked an article that shows auto vectorization in GCC > 4.7: > > http://locklessinc.com/**articles/vectorize/<http://locklessinc.com/articles/vectorize/> > > http://www.reddit.com/r/**programming/comments/tz6ml/** > autovectorization_with_gcc_47/<http://www.reddit.com/r/programming/comments/tz6ml/autovectorization_with_gcc_47/> > > GCC is good, it knows many tricks, it contains a lot of pattern matching > code and other code to allow such vectorizations, and that C code is almost > transparent & standard (restrict is standard, and I think > __builtin_assume_aligned isn't too much hard to #define away when not > available. And something like --fast-math is available on most compilers > (despite Walter doesn't like it)). So it's good to optimize legacy C code > too. > > But this article also shows why such strategy is not usable for serious > purposes. If small changes risk turning off such major optimizations, you > can't rely much on them. More generally, writing low-level code and hoping > the compiler recovers that high level semantics of the code is a bit > ridiculous. It's way better to express that semantics in a more direct way, > in a standard way that's understood by all compilers of a language (this > also because the code shown in that article has very simple semantics). > This is also why building a compiler that outputs C is a bad idea. Performance inevitably suffers because the C output must have same or tighter semantic requirements than the input code, and high level optimizations are more difficult.
