[llvm-dev] Early CSE clobbering llvm.assume

[Sean Silva via llvm-dev]

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>