On Sun, 29 Jun 2014, Ulrich Drepper wrote:
I think the Arm definitions come from a different angle. It's new, there is no assumed semantics.
Is it that new? I thought it was implemented based on a rather precise specification by ARM. Again, I don't really know arm.
For the x86 intrinsics Intel defines that _mm_xxx() generates one of a given opcodes if there is a match. If I want to generate a specific code sequence I use the intrinsics.
We already sometimes generate a different instruction than the name of the instrinsic suggests, or combine consecutive intrinsics into something else. I use inline asm when I want a specific code sequence.
Otherwise I could already today use the vector type semantics myself.
Well, the main reasons I use the intrinsics are: 1) the code compiles with visual studio 2) use the esoteric instructions (anything without a trivial mapping in C)
Don't get me wrong, I like the idea to have the optimization of the intrinsics happening. But perhaps not unconditionally or at least not without preventing them. I know this will look ugly, but how about a macro __GCC_X86_HONOR_INTRINSICS to enable the current code and have by default your proposed use of the vector arithmetic in place? This wouldn't allow removing support for the built-ins but it would also open the door to some more risky optimizations to be enabled by default.
That's a pretty big drawback. Instead of simplifying the implementation, it makes it more complicated. We also have to document the macro, update the testsuite so it tests the intrinsics in both modes, etc.
I understand the concern, and I would probably implement __GCC_X86_HONOR_INTRINSICS (though the testsuite part scares me as I have so little understanding of how it works, so I may need help), but I'd like to make sure first that the simpler approach is not acceptable, possibly with strong constraints on which operations are ok (_mm_load[hl]_pd could be removed from the patch for instance).
As another comparison, clang's version of *intrin.h uses the vector extensions much more than I am proposing.
-- Marc Glisse
