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>
On Sat, Jun 11, 2016 at 5:47 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:> Perhaps a naive question then is: why don't we represent assume as `if > (!cond) unreachable; else <the rest of the code>`?As I understand it, in theory this is fine, but in practice it may end up breaking optimizations. For instance, today we can hoist loads across calls to assume, but it may not be obviously safe if you have the branch-to-unreachable representation. The control flow representation may also bloat compile time / memory usage due to more basic blocks. -- Sanjoy
Daniel Berlin via llvm-dev
2016-Jun-12 01:17 UTC
[llvm-dev] Early CSE clobbering llvm.assume
What he said :) It also, representationally, has a related issue our current assume does in terms of figuring out the set of assumptions applied. Given an instruction, in extended SSA, because " assume" produces a value used by things, it's trivial to find the chain of assumptions you can use for it. In a straight control flow representation, it requires finding which side of the branch you are on all the way up the control dependence tree On Sat, Jun 11, 2016, 6:07 PM Sanjoy Das via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Sat, Jun 11, 2016 at 5:47 PM, Sean Silva via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > Perhaps a naive question then is: why don't we represent assume as `if > > (!cond) unreachable; else <the rest of the code>`? > > As I understand it, in theory this is fine, but in practice it may end > up breaking optimizations. For instance, today we can hoist loads > across calls to assume, but it may not be obviously safe if you have > the branch-to-unreachable representation. The control flow > representation may also bloat compile time / memory usage due to more > basic blocks. > > -- Sanjoy > _______________________________________________ > 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/20160612/5f4e6a46/attachment.html>