Björn Pettersson A via llvm-dev
2021-May-25 18:39 UTC
[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> On Behalf Of Philip
Reames via llvm-dev
Sent: den 25 maj 2021 17:42
To: Markus Lavin <markus.lavin at ericsson.com>; llvm-dev <llvm-dev at
lists.llvm.org>; jannh at google.com; 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/20210525/2838ed52/attachment.html>
Markus Lavin via llvm-dev
2021-May-26 06:58 UTC
[llvm-dev] llvm.assume after CodeGenPrepare
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/1fa965c5/attachment-0001.html>