[llvm-dev] LV: predication

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri May 1 13:11:07 PDT 2020

From: Sjoerd Meijer <Sjoerd.Meijer at arm.com>
Sent: Friday, May 1, 2020 11:54 AM
To: Eli Friedman <efriedma at quicinc.com>; llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] LV: predication

Hi Eli,

> 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 do see that point. But is that also not the beauty of it? It just sits in the preheader, if gets removed, then so be it. And if it not recognised, then also no harm done?

The harm comes if the intrinsic ends up with the wrong value, or attached to the wrong loop.

> Probably the simplest path to get this working is to derive the number of elements in the backend (in HardwareLoops, or your tail predication pass). You should be able to figure it from the masks used in the llvm.masked.load/store instructions in the loop.

This is what we are currently doing and works excellent for simpler cases. For the more complicated cases that we now what to handle as well, the pattern matching just becomes a bit too horrible, and it is fragile too. All we need is the information that the vectoriser already has, and pass this on somehow.

As I am really keen to simply our backend pass, would there be another way to pass this information on? If emitting an intrinsic is a blocker, could this be done with a loop annotation?

If the problem is specifically figuring out the underlying element count given a predicate, maybe we could attack it from that angle?  For example, introduce a special intrinsic for deriving the mask (sort of like the SVE whilelo).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200501/47022af0/attachment.html>

More information about the llvm-dev mailing list