[LLVMdev] Target intrinsics and translation

[Chris Lattner]

On Nov 14, 2011, at 3:01 PM, Dan Gohman wrote:
> LLVM (via clang) currently translates target intrinsics to generic IR
> whenever it can. For example, on x86 it translates _mm_loadu_pd to a
> simple load instruction with an alignment of 1. The backend is then
> responsible for translating the load back to the corresponding
> machine instruction.
> 
> The advantage of this is that it opens up such code to LLVM's
> optimizers, which can theoretically speed it up.
> 
> The disadvantage is that it's pretty surprising when intrinsics
> designed for the sole purpose of giving programmers access to specific
> machine instructions is translated to something other than those
> instructions. LLVM's optimizers aren't perfect, and there are many
> aspects of performance which they don't understand, so they can also
> pessimize code.
> 
> If the user has gone through the trouble of using target-specific
> intrinsics to ask for a specific sequence of machine instructions,
> is it really appropriate for the compiler to emit different
> instructions, using its own heuristics?

There are several benefits to doing it this way:

1. Fewer intrinsics in the compiler, fewer patterns in the targets, less redundancy.

2. The compiler should know better than the user, because code is often written and forgotten about.  The compiler can add value when building hand tuned and highly optimized SSE2 code for an SSE4 chip, for example.

3. If the compiler is pessimizing (e.g.) unaligned loads, then it is a serious bug that should be fixed, not something that should be worked around by adding intrinsics.  Adding intrinsics just makes it much less likely that we'd find out about it and then be able to fix it.

4. In practice, if we had intrinsics for everything, I strongly suspect that a lot of generic patterns wouldn't get written.  This would pessimize "portable" code using standard IR constructs.

-Chris