llvm dev - Sep 2019 - 回复: ScalarEvolution invariants around wrapping flags

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.

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>

On Sun, 29 Sep 2019 at 19:23, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
> Your reasoning sounds correct to me.  Let's revert for now?
Sounds good, I've reverted it with r373184 (and r373185 to polly,
which fixed up some tests after the original commit).
> 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)".
Oh yes, that didn't even occur to me.

Cheers.

Tim.

Thank for reverting it.

For the original issue in https://reviews.llvm.org/D64868, if we want to make
sure nsw can be correctly added to increment SCEV, we need to also check
isLoopEntryGuardedByCond? Is this a right way to go?

BRS//
Chen Zheng
________________________________
发件人: llvm-dev <llvm-dev-bounces at lists.llvm.org> 代表 Tim Northover via
llvm-dev <llvm-dev at lists.llvm.org>
发送时间: 2019年9月30日 15:45
收件人: Sanjoy Das <sanjoy at playingwithpointers.com>
抄送: LLVM Developers Mailing List <llvm-dev at lists.llvm.org>
主题: Re: [llvm-dev] ScalarEvolution invariants around wrapping flags

On Sun, 29 Sep 2019 at 19:23, Sanjoy Das <sanjoy at
playingwithpointers.com> wrote:
> Your reasoning sounds correct to me.  Let's revert for now?
Sounds good, I've reverted it with r373184 (and r373185 to polly,
which fixed up some tests after the original commit).
> 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)".
Oh yes, that didn't even occur to me.

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/20190930/19776cc8/attachment.html>