http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55457
--- Comment #2 from Siarhei Siamashka <siarhei.siamashka at gmail dot com> 2012-12-09 02:33:24 UTC --- (In reply to comment #1) > The whole point of the gcc vector extensions is that you don't need to depend > on what the hardware can do under neath as it should produce good code in > either case. I think that you are a bit too idealistic and overlooking some practical implications: 1. GCC just does not generate really good code with vector extensions when there is no real SIMD backend. 2. There may be some high level algorithmic optimizations possible. For example, branches to skip calculations for some special cases. We really want to have these branches in scalar code, while SIMD can sacrifice the branches and gain a lot more performance from parallel processing. So right now GCC is forcing me and the other users to infest the code with ifdefs checking for __x86__, __amd64__, __arm__, __powerpc__, __SSE2__, __ALTIVEC__, __ARM_NEON__, etc. to disable the use of vector extensions when there is actually no real SIMD. It kinda defeats the purpose, because turns out that I need to know about the existence of all the CPU architectures supported by GCC and their SIMD implementations before I can expect that the code will work reasonably fast everywhere. Relying just on GCC vector extensions means non-portable code, which will not work with the other compilers. So in any case, everyone is likely to already have an alternative implementation written in standard C. Having two alternative implementations to select from, we want to be able to make a reasonably good guess about which implementation is going to be preferable for this particular build.
