On Tue, Jul 19, 2016 at 9: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 The current behavior is to only warn possible missed loop optimization in IVOPT, which effectively is the last niter related loop optimization. I would rather to keep this behavior because warning against specific optimization would be a real hassle. This leads to another problem about precise warning message: If a loop optimization has already handled loop with assumptions, we should not warn against the loop afterwards. This again reminds me of the patch adding flag/constraint (or whatever the name finally made) extension. We can annotate loop structure once it's handled, so that warning message won't be issued. How about this?
> get aware of "assumptions" and deal with them. The first question needs to be answered is how we export assumptions to various loop optimizers. For now, I only added one specific interface number_of_iteration_exit_assumptions and this will only be used in vectorizer in my following patches. A generic method exporting assumptions in loop structure would be great, but that's difficult because sometime we not only need assumptions itself, but also need to analyzer scev under assumptions. This is another problem though. > 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. Yeah, this could be easily done using the flag/constraint method. Thanks, bin > > Richard. > >> Thanks, >> bin
