[PATCH] D57504: RFC: Prototype & Roadmap for vector predication in LLVM

[Simon Moll via Phabricator via llvm-commits]

simoll added a comment.

In D57504#1849694 <https://reviews.llvm.org/D57504#1849694>, @SjoerdMeijer wrote:

> (not sure if I should continue here or in D69891 <https://reviews.llvm.org/D69891>, will try here first)


Yep, the RFC is the right place for conceptual discussions.

> Sorry for dipping out of this discussion. I.e. after our "passthru discussion", I wanted to do more homework to make sure a "separate select" would work for us, if we wouldn't miss anything, but then other work happened and never got round to this. But I am still very interested, so dipping back in :-/

Welcome back :)

> 
> 
>> If we had predicated IR instructions, would we want them to have a passthru operand?
>> 
>>> I think that would probably be a reasonable clean-slate IR design, though I am not at all sure if it would be better.
> 
> One of the problems I had that I found it difficult to see all consequences, and answers the sort of questions asked above (also because I haven't yet spend enough time on this). For example, being explicit in IR is in general a good thing to do? So yes, why not a passthru? But then I had the same question as Robin, not sure it would be better. The other thing I would mention again is that I think convenience is a pretty strong argument too, if this is most convenient for at least two / three other architectures, then why not? But then you could argue that it is simple to patch up with a select, and we're going in circles... At least the concern Robin brought up about the select seems to be addressed with the vp.select.

Couldn't agree more. I guess we just do now know at this point.. how about we move the discussion away from "which would be better?" to "if we decide for A now and later strongly realize that B would have been the right call.. how bad a u-turn would that be?"

Changes required going from passthru to select:
-----------------------------------------------

- IR: modernize VP with passthru to intrinsic+select
- Nothing more.. since we already had to implement the select+intrinsic matching logic anyway to fuse explicit selects into passthru operands.
- Dead code: all the logic for dealing with the passthru operand: PatternMatch for passthru (instcombine, instsimplify, known bits..), etc

Changes required going from select to passthru:
-----------------------------------------------

- IR: modernize and pass 'undef' as passthru
- Implement that pass from the other scenario that folds select into passthru (and all the additional logic for dealing with passthru).
- Dead code: none

My point here is that no matter how we decide: explicit selects and vp intrinsics will co-exist and have to be folded/optimized. However, in the explicit-select scenario we do not have to teach LLVM about passthru operands (PatternMatch -> InstCombine, ...).
Btw, I guess that https://reviews.llvm.org/D71432 shows that op+select folding can be cleanly implemented in isel and that's also in line with my experiments for the VE target.
Regarding convenience: the IRBuilder could have, eg, a `::CreatePredicatedFAdd` with an explicit (optional) passthru operand..  resulting in a VP op + select.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57504/new/

https://reviews.llvm.org/D57504