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

[Sjoerd Meijer via Phabricator via llvm-commits]

SjoerdMeijer added a comment.



> 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?"
> 
>   1. 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
>   1. 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.

Thanks for summarising this. Fair enough, I think this sounds like a (good) plan.
I will continue in D69891 <https://reviews.llvm.org/D69891>, and will leave a comment there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57504