[LLVMdev] Predication on SIMD architectures and LLVM

[dag at cray.com]

Dan Gohman <dan433584 at gmail.com> writes:

> And, in part because a popular trend seems to be to have SIMD units
> which don't trap or raise exception flags on arithmetic and which don't
> go faster when predicated, such that there's no  reason to predicate
> anything except stores and occasionally loads. On these architectures,
> simply having intrinsics for stores, and perhaps loads, is basically
> sufficient, and less invasive.

This is going to change.  Intel recently released the ISA for Knights
Corner, a machine with general predication for SIMD.

http://software.intel.com/en-us/forums/topic/278102

> And, in part because predication is another wrinkle for SIMD
> performance portability. As people start caring more about SIMD
> performance, there will be more pressure to tune SIMD code in
> target-specific ways, and it erodes the benefit of a
> target-independent representation. This is a complex topic though, and
> there are multiple considerations, and not everyone agrees with me
> here.

It's true that a target-independent predicated IR isn't going to
translate well to a target that doesn't have predication.  However, for
targets that do it's a godsend.

> One thing that's initially counter-intuitive is that SIMD predication
> cannot be done in the same way as scalar or VLIW predication, where
> the majority of the compiler works as if it's on a "normal" scalar
> machine and predication happens during codegen, where the optimizer
> doesn't have to think about it. SIMD predication must be applied by
> whatever code is producing SIMD instructions, and in LLVM, that's
> typically in the optimizer or earlier.

Yep.  This is why I think IR support is essential.

                                 -David