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.
Thanks, bin
