[llvm-dev] [RFC] Vector Predication (original) (raw)

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 20 20:51:44 PST 2019

On 2/7/2019 9:28 AM, David Greene wrote:

Philip Reames <listmail at philipreames.com> writes:

Masking has advantages even in the default non-trapping fp environment: It is not uncommon for fp hardware to be slow on denormal values. If you take the operation + select approach, spurious computation on denomals could occur, slowing down the program. Why?  If you're backend has support for predicate fsub, you'd just pattern match for that. It's not that simple. Often the IR gets mangled so badly during optimization that the pattern is no longer recognizable. I've fixed bugs in LLVM where use of select to implement predication was causing traps because instcombine or something else lifted one of the operands of the select beyond a point where isel could match it. select is not semantically equivalent to predication and there is no way to force it to be without drastically changing the IR specification.

You misunderstood my point.

I was not suggesting that you rely on pattern matching predication for correctness.  As you point out, that's obviously incorrect.  I was assuming that you have a correct but slow lowering for the select form.  I was suggesting your ISEL attempt to use a predicated instruction where possible for performance.

The point about pattern complexity is an inherent difficulty w/any intermediate IR.  We do quite well pattern matching complicate constructs in existing backends - x86 SIMD comes to mind - and I'm unconvinced that predication is somehow inherently more difficult.

Philip

More information about the llvm-dev mailing list