On Tue, Jul 19, 2016 at 10:00 AM, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Jul 18, 2016 at 5:36 PM, Bin.Cheng <amker.ch...@gmail.com> wrote: >> On Mon, Jul 18, 2016 at 4:28 PM, NightStrike <nightstr...@gmail.com> wrote: >>> On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.ch...@gmail.com> wrote: >>>> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstr...@gmail.com> wrote: >>>>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <bin.ch...@arm.com> 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: >>>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71769 >>>>> >>>>> but some go back far, in this case 9 years: >>>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34114 >>>>> >>>>> 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? >> Hmm, good point, I will iterate the patch to see if I can only remove >> -funsafe-loop-optimizations, while keep -Wunsafe-loop-optimizations. > > Of course the naming of -Wunsafe-loop-optimizations is misleading then. > Maybe provide an alias -Wmissed-loop-optimizations and re-word it to > say "disable _some_ loop optimizations" as I hope more loop optimizations > get aware of "assumptions" and deal with them.
In which case a way to "re-introduce" -funsafe-loop-optimizations would be to add a #pragma that can be used to annotate loops to tell GCC of various properties like that it terminates without IV wrapping. Richard. > Richard. > >> Thanks, >> bin
