Not auto-vectorization

[Andrew Wiley]

On Tue, May 22, 2012 at 1:52 PM, bearophile <bearophileHUGS at lycos.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120522/e7c608ea/attachment.html>