[llvm-dev] [RFC] Vector Predication
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
>> 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.
More information about the llvm-dev