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

My (dumb?) question would be:  why is llvm.assume being handled any differently
than llvm.assert ?
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 ?

--Peter Lawrence.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160611/61b30fd1/attachment.html>

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/20160610/f81a3474/attachment.html>

Note:, the example would optimize if it was multiple blocks with an if.

The problem with assume is two fold:

1. Their is not proper control dependence infrastructure to know not to
move them, we rely on marking them as memory touching instructions, which
they are not. This causes all sorts of fun side-effects like adding assumes
causing things to go from readnone to readonly or readwrite, not just
during functionattrs, but during inlining, etc.

2. Their scope is implicit. Things have to track and figure out what they
apply to.

In extended-ssa (which is basically assume, if the assumes produced a value
that was used by things that make use of the information), all use-sites
are post-dominated by the conditional.


IE extended-ssa is something like

%2 = icmp eq %foo, 3
%3 = llvm.assume(%foo eq 3)
<use of %3 instead of %foo>

So for conditionals, it will produce two assumes, one in each branch, and
all things in that branch using %foo would instead use the result of the
assume for that side of the branch.






On Fri, Jun 10, 2016 at 5:38 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> 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/20160610/9bd69552/attachment.html>

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>