[llvm-dev] ScalarEvolution invariants around wrapping flags

Mehdi AMINI via llvm-dev llvm-dev at lists.llvm.org
Sun Sep 29 12:17:43 PDT 2019


This patch made it into clang-9.0, I would flag the revert for 9.1.

+Tom (I don't know the current process to flag patches for dot releases)

-- 
Mehdi


On Sun, Sep 29, 2019 at 11:23 AM Sanjoy Das via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Your reasoning sounds correct to me.  Let's revert for now?
>
> I don't think there is an easy fix, we'll have to do a global "must be
> executed" analysis to reapply the patch soundly.  And that's difficult
> since any external functional call can call "exit(0)".
>
> -- Sanjoy
>
> On Thu, Sep 26, 2019 at 6:19 AM Tim Northover <t.p.northover at gmail.com>
> wrote:
> >
> > Thanks for the information everyone, it's clarified my thinking
> > significantly. With that better understanding I've tracked the problem
> > I'm seeing down to r366419 (https://reviews.llvm.org/D64868), which
> > got committed in July.
> >
> > To me it looks like the patch is invalid because isAddRecNeverPoison
> > is a loop-relative computation. To add the flags to the increment we'd
> > need to know that the loop is guaranteed to execute at least once,
> > which doesn't really have a query available.
> >
> > Does that sound right? And if so should we revert it or try to
> > incorporate a loop-executed check? I probably tend towards revert.
> >
> > Cheers.
> >
> > Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20190929/6fbb39b6/attachment.html>


More information about the llvm-dev mailing list