Lawrence, Peter via llvm-dev
2016-Jun-11 00:59 UTC
[llvm-dev] Early CSE clobbering llvm.assume
Daniel,
Well then my next (dumb?) question is why aren’t we using source
level assert information
For optimization ?
--Peter Lawrence.
From: Daniel Berlin [mailto:dberlin at dberlin.org]
Sent: Friday, June 10, 2016 5:39 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
On Fri, Jun 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
My (dumb?) question would be: why is llvm.assume being handled any differently
than llvm.assert ?
There is no llvm.assert intrinsic, so i'm not sure what you mean here. Care
to give an example?
Other than one trapping and one not-trapping, they should be identical, in both
cases they are giving
The optimizers information, and that shouldn’t be any different from being
inside an “if” statement with the same condition ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/5c7b8588/attachment.html>
Daniel Berlin via llvm-dev
2016-Jun-11 01:32 UTC
[llvm-dev] Early CSE clobbering llvm.assume
We do, implicitly, because assert generates if conditions. Or at least, gvn knows how to propagate that implicit info. We can do better by exposing it more, most likely On Fri, Jun 10, 2016, 5:59 PM Lawrence, Peter <c_plawre at qca.qualcomm.com> wrote:> Daniel, > > Well then my next (dumb?) question is why aren’t we using > source level assert information > > For optimization ? > > > > --Peter Lawrence. > > > > > > *From:* Daniel Berlin [mailto:dberlin at dberlin.org] > *Sent:* Friday, June 10, 2016 5:39 PM > *To:* Lawrence, Peter <c_plawre at qca.qualcomm.com> > *Cc:* llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] Early CSE clobbering llvm.assume > > > > > > > > On Fri, Jun 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > My (dumb?) question would be: why is llvm.assume being handled any > differently than llvm.assert ? > > > > There is no llvm.assert intrinsic, so i'm not sure what you mean here. > Care to give an example? > > > > Other than one trapping and one not-trapping, they should be identical, in > both cases they are giving > > The optimizers information, and that shouldn’t be any different from > being inside an “if” statement with the same condition ? > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/e137ba37/attachment.html>
----- Original Message -----> From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Peter Lawrence" <c_plawre at qca.qualcomm.com> > Cc: llvm-dev at lists.llvm.org > Sent: Friday, June 10, 2016 8:32:06 PM > Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume> We do, implicitly, because assert generates if conditions. Or at > least, gvn knows how to propagate that implicit info. We can do > better by exposing it more, most likelyAre you asking why we don't assume the asserted condition when NDEBUG is defined? -Hal> On Fri, Jun 10, 2016, 5:59 PM Lawrence, Peter < > c_plawre at qca.qualcomm.com > wrote:> > Daniel, > > > Well then my next (dumb?) question is why aren’t we using source > > level assert information > > > For optimization ? >> > --Peter Lawrence. >> > From: Daniel Berlin [mailto: dberlin at dberlin.org ] > > > Sent: Friday, June 10, 2016 5:39 PM > > > To: Lawrence, Peter < c_plawre at qca.qualcomm.com > > > > Cc: llvm-dev at lists.llvm.org > > > Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume >> > On Fri, Jun 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev < > > llvm-dev at lists.llvm.org > wrote: > > > > My (dumb?) question would be: why is llvm.assume being handled > > > any > > > differently than llvm.assert ? > > > > > There is no llvm.assert intrinsic, so i'm not sure what you mean > > here. Care to give an example? >> > > Other than one trapping and one not-trapping, they should be > > > identical, in both cases they are giving > > > > > > The optimizers information, and that shouldn’t be any different > > > from > > > being inside an “if” statement with the same condition ? > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160610/bab88259/attachment.html>
Lawrence, Peter via llvm-dev
2016-Jun-11 02:00 UTC
[llvm-dev] Early CSE clobbering llvm.assume
Daniel,
My point is this,
If (cond) ---- optimizer takes advantage of knowing cond == true within the
“then” part
Assert(cond) ---- optimizer takes advantage of knowing cond == true for the rest
of the scope
Assume(cond) ---- optimizer takes advantage of knowing cond == true for the rest
of the scope
If we aren’t implementing these in a consistent manner (like using an intrinsic
for one but not the others)
Then we aren’t doing a good job of engineering,
IE we should be able to get “assume” to work for free if we are doing it right.
Asking “how do I get this intrinsic to work” is perhaps the wrong question,
Perhaps the right question is, how do we represent assume so that we get it for
free.
---Peter Lawrence.
From: Daniel Berlin [mailto:dberlin at dberlin.org]
Sent: Friday, June 10, 2016 6:32 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
We do, implicitly, because assert generates if conditions. Or at least, gvn
knows how to propagate that implicit info. We can do better by exposing it more,
most likely
On Fri, Jun 10, 2016, 5:59 PM Lawrence, Peter <c_plawre at
qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:
Daniel,
Well then my next (dumb?) question is why aren’t we using source
level assert information
For optimization ?
--Peter Lawrence.
From: Daniel Berlin [mailto:dberlin at dberlin.org<mailto:dberlin at
dberlin.org>]
Sent: Friday, June 10, 2016 5:39 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at
qca.qualcomm.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
On Fri, Jun 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
My (dumb?) question would be: why is llvm.assume being handled any differently
than llvm.assert ?
There is no llvm.assert intrinsic, so i'm not sure what you mean here. Care
to give an example?
Other than one trapping and one not-trapping, they should be identical, in both
cases they are giving
The optimizers information, and that shouldn’t be any different from being
inside an “if” statement with the same condition ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/d0550b3c/attachment.html>
Lawrence, Peter via llvm-dev
2016-Jun-11 02:33 UTC
[llvm-dev] Early CSE clobbering llvm.assume
Daniel,
Allow me to elaborate some more...
You seem to be trying to get “Constant-propagation” out of an “assume”,
But a good compiler does so much more
* if(A > B), assert(A > B), assume(A > B), should
all result in same optimizations
* if(A>B && A<C), assert(A>B && A<C),
assume(A>B & A<C), should all result in same optimizations
* if(A & 0x1), assert(A & 0x1), assume(A & 0x1),
should all result in same optimizations
* if(A & (A-1)), assert(A & (A-1)), assume(A & (A-1)),
should all result in same optimizations
OK, maybe the last one, or two, are a stretch, maybe we only want to generalize
to
Value-propagation, and Range-propagation, and not arbitrary
Property-propagation,
But this should be the goal,
The question is, is an “intrinsic” the right way to go about it.
--Peter Lawrence.
From: Daniel Berlin [mailto:dberlin at dberlin.org]
Sent: Friday, June 10, 2016 6:32 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com>
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
We do, implicitly, because assert generates if conditions. Or at least, gvn
knows how to propagate that implicit info. We can do better by exposing it more,
most likely
On Fri, Jun 10, 2016, 5:59 PM Lawrence, Peter <c_plawre at
qca.qualcomm.com<mailto:c_plawre at qca.qualcomm.com>> wrote:
Daniel,
Well then my next (dumb?) question is why aren’t we using source
level assert information
For optimization ?
--Peter Lawrence.
From: Daniel Berlin [mailto:dberlin at dberlin.org<mailto:dberlin at
dberlin.org>]
Sent: Friday, June 10, 2016 5:39 PM
To: Lawrence, Peter <c_plawre at qca.qualcomm.com<mailto:c_plawre at
qca.qualcomm.com>>
Cc: llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] Early CSE clobbering llvm.assume
On Fri, Jun 10, 2016 at 5:34 PM, Lawrence, Peter via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
My (dumb?) question would be: why is llvm.assume being handled any differently
than llvm.assert ?
There is no llvm.assert intrinsic, so i'm not sure what you mean here. Care
to give an example?
Other than one trapping and one not-trapping, they should be identical, in both
cases they are giving
The optimizers information, and that shouldn’t be any different from being
inside an “if” statement with the same condition ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/466882b6/attachment.html>