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>
Lawrence, Peter via llvm-dev
2016-Jun-14 17:36 UTC
[llvm-dev] Early CSE clobbering llvm.assume
Daniel, What am I missing in the following chain of logic: As far as constant-prop, value-prop, range-prop, and general property-propagation, 1. the compiler/optimizer *has* to get it right for if-then-else and while-do or else we should all start over ☺ 2. “assert” takes advantage of this by being translated into if-then logic early on in the compilation 3. “assume” should also take advantage of this the same way. (generate a call to “pseudoabort” which At some late stage gets deleted) Sanjoy’s argument is faulty, if it were true we would also find our handling of “assert” to be unacceptable but this is not the case, no one is arguing that we need to re-design “assert”. And any argument you can make about needing to handle “assume” conditions in some special way can be Turned around and applied to “if-then” conditions, but again no one is arguing that we need to re-design “if-then” Information propagation. Thanks, --Peter. From: Daniel Berlin [mailto:dberlin at dberlin.org] Sent: Saturday, June 11, 2016 6:17 PM To: Sanjoy Das <sanjoy at playingwithpointers.com>; Sean Silva <chisophugis at gmail.com> Cc: Lawrence, Peter <c_plawre at qca.qualcomm.com>; llvm-dev at lists.llvm.org Subject: Re: [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<mailto: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<mailto: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<mailto: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/20160614/583c6994/attachment.html>
Daniel Berlin via llvm-dev
2016-Jun-14 17:45 UTC
[llvm-dev] Early CSE clobbering llvm.assume
On Tue, Jun 14, 2016 at 10:36 AM, Lawrence, Peter <c_plawre at qca.qualcomm.com> wrote:> Daniel, > > What am I missing in the following chain of logic: > > > > As far as constant-prop, value-prop, range-prop, and general > property-propagation, > > > > 1. the compiler/optimizer **has** to get it right for if-then-else and > while-do or else we should all start over J >Only certain parts of the compiler know how to do this. This is precisely one of the reasons i'm proposing we've gotten it wrong.> > > 2. “assert” takes advantage of this by being translated into if-then logic > early on in the compilation > > > > 3. “assume” should also take advantage of this the same way. (generate a > call to “pseudoabort” which > > At some late stage gets deleted) >This would fix precisely nothing, because of the above.> > > Sanjoy’s argument is faulty, if it were true we would also find our > handling of “assert” to be unacceptable > > but this is not the case, no one is arguing that we need to re-design > “assert”. >Asserts occur much more often than assumes, it may or may not be sensible to handle them the same way. I would argue it is sensible, but it's also reasonable to argue it is not. I would also argue our current way of propagating information for if-then conditions is in fact, quite crappy. Only a small number of passes know how to do it, and they do it either by ad-hoc analysis (GVN) or very expensive methods (LVI).> > > And any argument you can make about needing to handle “assume” conditions > in some special way can be > > Turned around and applied to “if-then” conditions, but again no one is > arguing that we need to re-design “if-then” > > Information propagation. >I would argue we do, in fact need to do that. That said, it is a larger longer term change. Fixing assume is a good start on that, and by fixing assume, we can prove out whether a new model will work well and expand it. If we start by trying to fix the general propagation problem, that's a huge job to start, and if we get it wrong, a lot larger to fix. Better to start small and go from there. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160614/035bd731/attachment.html>