thr3ads.net - llvm dev - [llvm-dev] Early CSE clobbering llvm.assume [Jun 2016]

If this information is useful, please help other people find it:
Share via:

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>

Mehdi Amini via llvm-dev

2016-Jun-11 04:58 UTC

head link

[llvm-dev] Early CSE clobbering llvm.assume

Hi,
> On Jun 10, 2016, at 7:00 PM, Lawrence, Peter via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 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,
It is not clear cut for me.
First the Assert(cond) is not an llvm construct AFAIK. At the source level it is
usually a macro that turns into `if (!Cond) abort()` and thus can be reduced to
your first case.
(Also I believe it disappears in optimized build and the optimizer/LLVM will
never see the test).

And second, it seems to me that there is a fundamental difference between the
first and last case: in the first case the optimizer deduces some properties
from the control flow (i.e. cond==true within the "then" part), while
in the assume case it is an information that the optimizer can't deduce
itself, and that is *not related to the control flow* but is present thanks to a
hint from the programmer (or the front-end).

It is not clear that these two sources of information can be reconcile easily
with a common representation.
> IE we should be able to get “assume” to work for free if we are doing it
right.
I'm not sure what you mean by "work for free"?

-- 
Mehdi
>  
> 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 ?
>  
>  
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160610/6b172e49/attachment.html>

Sean Silva via llvm-dev

2016-Jun-12 00:47 UTC

head link

[llvm-dev] Early CSE clobbering llvm.assume

On Fri, Jun 10, 2016 at 9:58 PM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> On Jun 10, 2016, at 7:00 PM, Lawrence, Peter via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> 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,
>
>
> It is not clear cut for me.
> First the Assert(cond) is not an llvm construct AFAIK. At the source level
> it is usually a macro that turns into `if (!Cond) abort()` and thus can be
> reduced to your first case.
> (Also I believe it disappears in optimized build and the optimizer/LLVM
> will never see the test).
>
> And second, it seems to me that there is a fundamental difference between
> the first and last case: in the first case the optimizer deduces some
> properties from the control flow (i.e. cond==true within the
"then" part),
> while in the assume case it is an information that the optimizer can't
> deduce itself, and that is *not related to the control flow* but is present
> thanks to a hint from the programmer (or the front-end).
>
> It is not clear that these two sources of information can be reconcile
> easily with a common representation.
>
Perhaps a naive question then is: why don't we represent assume as `if
(!cond) unreachable; else <the rest of the code>`?

-- Sean Silva


> IE we should be able to get “assume” to work for free if we are doing it
> right.
>
>
> I'm not sure what you mean by "work for free"?
>
> --
> Mehdi
>
>
> 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 <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>
> 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
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/4aea74a0/attachment.html>

llvm dev - Jun 2016 - Early CSE clobbering llvm.assume

[llvm-dev] Early CSE clobbering llvm.assume

[llvm-dev] Early CSE clobbering llvm.assume

[llvm-dev] Early CSE clobbering llvm.assume