[LLVMdev] Predication on SIMD architectures and LLVM

dag at cray.com dag at cray.com
Mon Oct 22 10:15:49 PDT 2012

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.


> 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.


More information about the llvm-dev mailing list