[llvm-dev] [RFC] Vector Predication

[Philip Reames via llvm-dev]

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