[llvm-dev] LV: predication

[Renato Golin via llvm-dev]

On Fri, 1 May 2020 at 19:30, Eli Friedman via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The problem with your proposal, as written, is that the vectorizer is producing the intrinsic.  Because we don’t impose any ordering on optimizations before codegen, every optimization pass in LLVM would have to be taught to preserve any @llvm.set.loop.elements.i32 whenever it makes any change.  This is completely impractical because the intrinsic isn’t related to anything optimizations would normally look for: it’s a random intrinsic in the middle of nowhere.

I agree. Requiring a loose intrinsic to have meaning in the CFG is a
non-starter. That's why we have loop annotations.

To me, this looks like what MLIR has in the Loop or Affine dialects.
It would be great to have that in LLVM as well, for the cases where we
know it from the front-end (for ex. when lowering from MLIR), but this
has to be a loop annotation of some form.

A pass that generates such annotations could run just before loop
optimisations, or it could come from the front-end and hope it doesn't
get removed by some pass in between.

Fortran is bound to have more semantically rich loop information, and
they'll use MLIR. It would be interesting to know how that will be
done, and you could get the ground work done beforehand by working
with them to carry the annotations in the right way.

cheers,
--renato