[llvm-dev] Early CSE clobbering llvm.assume

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Tue Jun 14 10:45:50 PDT 2016


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>


More information about the llvm-dev mailing list