[llvm-dev] Early CSE clobbering llvm.assume

[Daniel Berlin via llvm-dev]

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>