[llvm-dev] llvm.assume after CodeGenPrepare

[Philip Reames via llvm-dev]

My second point should still stand.  Not caring about the MI 
representation does simplify the work involved, so that's a good 
observation.

Philip

On 5/25/21 11:58 PM, Markus Lavin wrote:
>
> That is correct. The only use case I am interested in is when AA is 
> queried during scheduling of MI and as Bjorn points out (and afaiu) 
> this falls back on assumes being present in the IR. The fact that AA, 
> during the MI layer, falls back on IR can indeed seem a bit strange 
> but that is simply how it works and not directly related to the 
> presence of assumes or not.
>
> AFAIU llvm.assume will iselect to nothing (which effectively also 
> eliminates its predecessors if the llvm.assume was their only use) so 
> at least for this use case no explicit llvm.assume representation is 
> required in the MI layer. The requirement would possibly be different 
> if there were other uses of llvm.assume in the MI layer but I am not 
> sure what they would be.
>
> -Markus
>
> *From:*Björn Pettersson A <bjorn.a.pettersson at ericsson.com>
> *Sent:* den 25 maj 2021 20:39
> *To:* Philip Reames <listmail at philipreames.com>; Markus Lavin 
> <markus.lavin at ericsson.com>; jannh at google.com; nikita.ppv at gmail.com; 
> llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* RE: [llvm-dev] llvm.assume after CodeGenPrepare
>
> I think Markus use case is that MachineInstr::mayAlias may use AA (and 
> even possibly TBAA), and AA could make use of llvm.assume to make 
> decisions.
>
> So the alias analysis in cadegen is partly based on analysing the 
> “final” IR representation before ISel, so the llvm.assume does not 
> need to be present in the MI layer for that to work.
>
> PS. It might seem a bit strange and dangerous to use the IR and IR 
> analyses during the codegen (e.g. afte PHI elimination), but afaik it 
> works as long as MachineMemOperands are handled correctly (being 
> dropped or updated correctly when doing certain transforms such as 
> store merging).
>
> /Björn
>
> *From:*llvm-dev <llvm-dev-bounces at lists.llvm.org 
> <mailto:llvm-dev-bounces at lists.llvm.org>> *On Behalf Of *Philip Reames 
> via llvm-dev
> *Sent:* den 25 maj 2021 17:42
> *To:* Markus Lavin <markus.lavin at ericsson.com 
> <mailto:markus.lavin at ericsson.com>>; llvm-dev <llvm-dev at lists.llvm.org 
> <mailto:llvm-dev at lists.llvm.org>>; jannh at google.com 
> <mailto:jannh at google.com>; nikita.ppv at gmail.com 
> <mailto:nikita.ppv at gmail.com>
> *Subject:* Re: [llvm-dev] llvm.assume after CodeGenPrepare
>
> I think there's two interacting pieces here:
>
>   * I don't believe we have a way to represent an assume at the MI
>     layer.  If we let them flow through codegen, we'd need to add such
>     a thing.
>   * The tradeoffs between information preservation and lowering may be
>     different at different points in the pipeline.  Johannes frames
>     this as a canonicalization problem.  That sounds reasonable, but
>     it's also reasonable that we may need to give up on preserving
>     assumes at some point.  (As a silly example, we probably don't
>     want them at MC.) Where exactly that point is unclear, and is
>     mostly a matter of practical engineering tradeoffs.
>
> If you felt like exploring alternate lowering points, that would seem 
> entirely reasonable. It might not work out, or it might require a 
> bunch of work to make happen, but the basic idea seems entirely worth 
> exploring.
>
> Philip
>
> On 5/25/21 3:11 AM, Markus Lavin via llvm-dev wrote:
>
>     With recent changes in BasicAA (mostly by Nikita Popov I believe)
>     llvm.assumes can now guide in the AA decision making. Which is of
>     course great.
>
>     For example for C input (or IR equivalent) as follows it can make
>     a huge difference if the variable ‘x’ is known to be non-zero when
>     AA is queried during scheduling
>
>     __builtin_assume(x != 0);
>
>     for (int i = 0; i < 64; i += 4) {
>
>       v[(i + 0) * x] = v[(i + 0) * x] >> 2;
>
>       v[(i + 1) * x] = v[(i + 1) * x] >> 2;
>
>       v[(i + 2) * x] = v[(i + 2) * x] >> 2;
>
>       v[(i + 3) * x] = v[(i + 3) * x] >> 2;
>
>     }
>
>     Unfortunately it appears that the CodeGenPrepare pass removes
>     llvm.assume so that they never reach the code generator. Currently
>     commit 91c9dee3fb6d89ab3 (and before that commit
>     6d20937c29a1a1d67) eliminate assumptions in CodeGenPrepare for
>     reasons that appear to be optimization (avoiding blocks that would
>     be empty if it was not for the llvm.assume and its predecessors).
>
>     It seems these two efforts are quite contradictory. Is there any
>     deeper thinking behind this? I for one would be in favor of not
>     eliminating assumes.
>
>     -Markus
>
>     _______________________________________________
>
>     LLVM Developers mailing list
>
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>
>     https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>     <https://protect2.fireeye.com/v1/url?k=efdd418c-b0467bc9-efdd0117-867b36d1634c-7a75399069504f9e&q=1&e=17991efb-205e-4418-bc44-152a2fed67d4&u=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fllvm-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210526/8adf88b8/attachment.html>