[llvm-dev] Speculation and control dependent no wrap flags

[Philip Reames via llvm-dev]

Personally, I'm in the "strip like metadata" camp.  This is much easier 
to reason about.

Philip

On 02/03/2017 07:50 AM, Reid Kleckner via llvm-dev wrote:
> Just yesterday I talked to Dan Gohman, who suggested we strip nowrap 
> flags when speculating. It solves a lot of poison problems.
>
> On Feb 3, 2017 5:49 AM, "Hal Finkel via llvm-dev" 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>
>     On 02/03/2017 07:28 AM, Artur Pilipenko wrote:
>
>         I'm looking at the bug
>         (https://llvm.org/bugs/show_bug.cgi?id=31181
>         <https://llvm.org/bugs/show_bug.cgi?id=31181>) which was
>         triggered by my change to make CVP mark adds as no wrap
>         (https://reviews.llvm.org/rL278220
>         <https://reviews.llvm.org/rL278220>) and I'd like to have some
>         broader discussion of the problem. In this bug CVP correctly
>         marks an add as nuw basing on the loop latch check, but later
>         loop rotation pass moves the add to a point before the check.
>         In the new context nuw is no longer valid and leads to an
>         incorrect transformation of the loop. See
>         https://llvm.org/bugs/show_bug.cgi?id=31181#c5
>         <https://llvm.org/bugs/show_bug.cgi?id=31181#c5> comment in
>         the bug for more details.
>
>         Since nsw, nuw flags can be control dependent, it seems like
>         we should be treating them as metadata, i.e. we should be
>         stripping them when we speculate the instruction. I don’t
>         think that we are doing this now anywhere. The problem was
>         noticed on loop rotation, but I expect any other pass which
>         speculates overflowing operations is suffering from the same
>         problem.
>
>         Thoughts?
>
>
>     We generally don't strip these because violating the wrapping
>     constraint does not immediately cause UB. Instead, it generates a
>     poison value. So long as that poison value is not used in way
>     which causes UB, then everything is fine. In this case, I suspect
>     that we want to fix IndVars to strip the flag, or not do the
>     transformation, when it might introduce this kind of issue (i.e. a
>     situation where we might branch on a poison value).
>
>      -Hal
>
>
>         Artur
>
>
>     -- 
>     Hal Finkel
>     Lead, Compiler Technology and Programming Languages
>     Leadership Computing Facility
>     Argonne National Laboratory
>
>     _______________________________________________
>     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
>     <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/20170203/fa1ae66f/attachment-0001.html>