This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <> wrote:
> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <> wrote:
>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <> wrote:
>>> Hi,
>>> This patch removes support for -funsafe-loop-optimizations, as well as -Wunsafe-loop-optimizations.  By its name, this option does unsafe optimizations by assuming all loops must terminate and doesn't wrap.  Unfortunately, it's not as useful as expected because:
>>> 1) Simply assuming loop must terminate isn't enough.  What we really want is to analyze scalar evolution and loop niter bound under such assumptions.  This option does nothing in this aspect.
>>> 2) IIRC, this option generates bogus code for some common programs, that's why it's disabled by default even at Ofast level.
>>> After I sent patches handling possible infinite loops in both (scev/niter) analyzer and vectorizer, it's a natural step to remove such options in GCC.  This patch does so by deleting code for -funsafe-loop-optimizations, as well as -Wunsafe-loop-optimizations.  It also deletes the two now useless tests, while the option interface is preserved for backward compatibility purpose.
>> There are a number of bugs opened against those options, including one
>> that I just opened rather recently:
>> but some go back far, in this case 9 years:
>> If you are going to remove the options, you should address open bugs
>> related to those options.
> Hi,
> Thanks for pointing me to these PRs, I will have a look at them.

I only highlighted two PRs, I was suggesting that you look for all of them.

> IMHO, the old one reports weakness in loop niter analyzer, the issue
> exists whether I remove unsafe-loop-optimization or not.  The new one
> is a little bit trickier, I will put some comments on PR, and again,
> the issue (if it is) is in niter analyzer which has nothing to do with
> the option really.

Well, one thing to note is that the warning is an easy way to get a
notice of a possible missed optimization (and I have many more
occurrences of it in a particular code base that I use).  If the
warning is highlighted potential issues that aren't due to the -f
option but are issues nonetheless, and we remove the warning, then how
should I go about finding these missed opportunities in the future?
Is there a different mechanism that does the same thing?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]