| Message ID | HE1PR0801MB17555AF75D185CC9D9E685EDE7330@HE1PR0801MB1755.eurprd08.prod.outlook.com |
|---|---|
| State | New |
| Headers | show |
On 07/15/2016 07:07 PM, Bin Cheng wrote:
> Bootstrap and test on x86_64. Is it OK?
If you do this you'll also need to remove the use in config/bfin.
Bernd
On July 15, 2016 7:16:42 PM GMT+02:00, Bernd Schmidt <bschmidt@redhat.com> wrote: >On 07/15/2016 07:07 PM, Bin Cheng wrote: > >> Bootstrap and test on x86_64. Is it OK? > >If you do this you'll also need to remove the use in config/bfin. OK with that change. Richard. > >Bernd
On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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.
On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: > On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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. 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. Thanks, bin
On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.cheng@gmail.com> wrote: > On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: >> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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?
On Mon, Jul 18, 2016 at 4:28 PM, NightStrike <nightstrike@gmail.com> wrote: > On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.cheng@gmail.com> wrote: >> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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
On Mon, Jul 18, 2016 at 5:36 PM, Bin.Cheng <amker.cheng@gmail.com> wrote: > On Mon, Jul 18, 2016 at 4:28 PM, NightStrike <nightstrike@gmail.com> wrote: >> On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.cheng@gmail.com> wrote: >>> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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. Richard. > Thanks, > bin
On Tue, Jul 19, 2016 at 10:00 AM, Richard Biener <richard.guenther@gmail.com> wrote: > On Mon, Jul 18, 2016 at 5:36 PM, Bin.Cheng <amker.cheng@gmail.com> wrote: >> On Mon, Jul 18, 2016 at 4:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>> On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.cheng@gmail.com> wrote: >>>> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>>>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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
Hi, On Mon, Jul 18, 2016 at 11:28:48AM -0400, NightStrike wrote: > 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? Yes, -fopt-info and -fopt-info-OPTIONS switches. It certainly seems to be a more natural means for manual compiler-guided optimization than warnings. Martin
On Tue, Jul 19, 2016 at 9:00 AM, Richard Biener <richard.guenther@gmail.com> wrote: > On Mon, Jul 18, 2016 at 5:36 PM, Bin.Cheng <amker.cheng@gmail.com> wrote: >> On Mon, Jul 18, 2016 at 4:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>> On Mon, Jul 18, 2016 at 3:55 AM, Bin.Cheng <amker.cheng@gmail.com> wrote: >>>> On Sat, Jul 16, 2016 at 6:28 PM, NightStrike <nightstrike@gmail.com> wrote: >>>>> On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng <Bin.Cheng@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
diff --git a/gcc/common.opt b/gcc/common.opt index a7c5125..331e1da 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -625,8 +625,8 @@ Common Var(warn_null_dereference) Warning Warn if dereferencing a NULL pointer may lead to erroneous or undefined behavior. Wunsafe-loop-optimizations -Common Var(warn_unsafe_loop_optimizations) Warning -Warn if the loop cannot be optimized due to nontrivial assumptions. +Common Ignore +Does nothing. Preserved for backward compatibility. Wmissing-noreturn Common Warning Alias(Wsuggest-attribute=noreturn) @@ -2500,8 +2500,8 @@ Perform loop unrolling for all loops. ; that control loops do not overflow and that the loops with nontrivial ; exit condition are not infinite funsafe-loop-optimizations -Common Report Var(flag_unsafe_loop_optimizations) Optimization -Allow loop optimizations to assume that the loops behave in normal way. +Common Ignore +Does nothing. Preserved for backward compatibility. fassociative-math Common Report Var(flag_associative_math) SetByCombined Optimization diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index ca8c1b4..4241956 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -302,8 +302,7 @@ Objective-C and Objective-C++ Dialects}. -Wswitch -Wswitch-bool -Wswitch-default -Wswitch-enum @gol -Wswitch-unreachable -Wsync-nand @gol -Wsystem-headers -Wtautological-compare -Wtrampolines -Wtrigraphs @gol --Wtype-limits -Wundef @gol --Wuninitialized -Wunknown-pragmas -Wunsafe-loop-optimizations @gol +-Wtype-limits -Wundef -Wuninitialized -Wunknown-pragmas @gol -Wunsuffixed-float-constants -Wunused -Wunused-function @gol -Wunused-label -Wunused-local-typedefs -Wunused-parameter @gol -Wno-unused-result -Wunused-value @gol -Wunused-variable @gol @@ -414,7 +413,7 @@ Objective-C and Objective-C++ Dialects}. -ftree-switch-conversion -ftree-tail-merge -ftree-ter @gol -ftree-vectorize -ftree-vrp -funconstrained-commons @gol -funit-at-a-time -funroll-all-loops -funroll-loops @gol --funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops @gol +-funsafe-math-optimizations -funswitch-loops @gol -fipa-ra -fvariable-expansion-in-unroller -fvect-cost-model -fvpt @gol -fweb -fwhole-program -fwpa -fuse-linker-plugin @gol --param @var{name}=@var{value} @@ -4986,14 +4985,6 @@ If the stack usage is (partly) dynamic and not bounded, it's: @end smallexample @end itemize -@item -Wunsafe-loop-optimizations -@opindex Wunsafe-loop-optimizations -@opindex Wno-unsafe-loop-optimizations -Warn if the loop cannot be optimized because the compiler cannot -assume anything on the bounds of the loop indices. With -@option{-funsafe-loop-optimizations} warn if the compiler makes -such assumptions. - @item -Wno-pedantic-ms-format @r{(MinGW targets only)} @opindex Wno-pedantic-ms-format @opindex Wpedantic-ms-format @@ -6817,15 +6808,6 @@ number of iterations of a loop are used to guide loop unrolling and peeling and loop exit test optimizations. This option is enabled by default. -@item -funsafe-loop-optimizations -@opindex funsafe-loop-optimizations -This option tells the loop optimizer to assume that loop indices do not -overflow, and that loops with nontrivial exit condition are not -infinite. This enables a wider range of loop optimizations even if -the loop optimizer itself cannot prove that these assumptions are valid. -If you use @option{-Wunsafe-loop-optimizations}, the compiler warns you -if it finds this kind of loop. - @item -funconstrained-commons @opindex funconstrained-commons This option tells the compiler that variables declared in common blocks diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c index da29d22..6b2cf96 100644 --- a/gcc/ipa-inline-analysis.c +++ b/gcc/ipa-inline-analysis.c @@ -2820,7 +2820,7 @@ estimate_function_body_sizes (struct cgraph_node *node, bool early) exits = get_loop_exit_edges (loop); FOR_EACH_VEC_ELT (exits, j, ex) - if (number_of_iterations_exit (loop, ex, &niter_desc, false) + if (number_of_iterations_exit (loop, ex, &niter_desc) && !is_gimple_min_invariant (niter_desc.niter)) { predicate will_be_nonconstant diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c index 57fb8c1..b3d41604 100644 --- a/gcc/loop-iv.c +++ b/gcc/loop-iv.c @@ -3027,42 +3027,6 @@ get_simple_loop_desc (struct loop *loop) iv_analysis_loop_init (loop); find_simple_exit (loop, desc); loop->simple_loop_desc = desc; - - if (desc->simple_p && (desc->assumptions || desc->infinite)) - { - const char *wording; - - /* Assume that no overflow happens and that the loop is finite. - We already warned at the tree level if we ran optimizations there. */ - if (!flag_tree_loop_optimize && warn_unsafe_loop_optimizations) - { - if (desc->infinite) - { - wording = - flag_unsafe_loop_optimizations - ? N_("assuming that the loop is not infinite") - : N_("cannot optimize possibly infinite loops"); - warning (OPT_Wunsafe_loop_optimizations, "%s", - gettext (wording)); - } - if (desc->assumptions) - { - wording = - flag_unsafe_loop_optimizations - ? N_("assuming that the loop counter does not overflow") - : N_("cannot optimize loop, the loop counter may overflow"); - warning (OPT_Wunsafe_loop_optimizations, "%s", - gettext (wording)); - } - } - - if (flag_unsafe_loop_optimizations && single_exit (loop)) - { - desc->assumptions = NULL_RTX; - desc->infinite = NULL_RTX; - } - } - return desc; } diff --git a/gcc/predict.c b/gcc/predict.c index 66a88ab..373000f 100644 --- a/gcc/predict.c +++ b/gcc/predict.c @@ -1774,7 +1774,7 @@ predict_loops (void) } predict_extra_loop_exits (ex); - if (number_of_iterations_exit (loop, ex, &niter_desc, false, false)) + if (number_of_iterations_exit (loop, ex, &niter_desc, false)) niter = niter_desc.niter; if (!niter || TREE_CODE (niter_desc.niter) != INTEGER_CST) niter = loop_niter_by_eval (loop, ex); diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c deleted file mode 100644 index 906132c..0000000 --- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-1.c +++ /dev/null @@ -1,29 +0,0 @@ -/* { dg-do compile } */ -/* { dg-options "-O2 -Wunsafe-loop-optimizations" } */ -extern void g(void); - -void -f (unsigned n) -{ - unsigned k; - for(k = 0;k <= n;k++) /* { dg-warning "cannot optimize.*infinite loops" } */ - g(); - - for(k = 0;k <= n;k += 4) /* { dg-warning "cannot optimize.*overflow" } */ - g(); - - /* We used to get warning for this loop. However, since then # of iterations - analysis improved, and we can now prove that this loop does not verflow. - This is because the only case when it would overflow is if n = ~0 (since - ~0 is divisible by 5), and this cannot be the case, since when we got - here, the previous loop exited, thus there exists k > n. */ - for(k = 5;k <= n;k += 5) - g(); - - /* So we need the following loop, instead. */ - for(k = 4;k <= n;k += 5) /* { dg-warning "cannot optimize.*overflow" } */ - g(); - - for(k = 15;k >= n;k--) /* { dg-warning "cannot optimize.*infinite" } */ - g(); -} diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c b/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c deleted file mode 100644 index 9116e97..0000000 --- a/gcc/testsuite/gcc.dg/tree-ssa/pr19210-2.c +++ /dev/null @@ -1,29 +0,0 @@ -/* { dg-do compile } */ -/* { dg-options "-O2 -funsafe-loop-optimizations -Wunsafe-loop-optimizations" } */ -extern void g(void); - -void -f (unsigned n) -{ - unsigned k; - for(k = 0;k <= n;k++) /* { dg-warning "assuming.*not infinite" } */ - g(); - - for(k = 5;k <= n;k += 4) /* { dg-warning "assuming.*not overflow" } */ - g(); - - /* We used to get warning for this loop. However, since then # of iterations - analysis improved, and we can now prove that this loop does not verflow. - This is because the only case when it would overflow is if n = ~0 (since - ~0 is divisible by 5), and this cannot be the case, since when we got - here, the previous loop exited, thus there exists k > n. */ - for(k = 5;k <= n;k += 5) - g(); - - for(k = 4;k <= n;k += 5) /* { dg-warning "assuming.*not overflow" } */ - g(); - - for(k = 15;k >= n;k--) /* { dg-warning "assuming.*not infinite" } */ - g(); - -} diff --git a/gcc/tree-parloops.c b/gcc/tree-parloops.c index 1303ffc..be4f4fa 100644 --- a/gcc/tree-parloops.c +++ b/gcc/tree-parloops.c @@ -2609,7 +2609,7 @@ try_get_loop_niter (loop_p loop, struct tree_niter_desc *niter) /* We need to know # of iterations, and there should be no uses of values defined inside loop outside of it, unless the values are invariants of the loop. */ - if (!number_of_iterations_exit (loop, exit, niter, false)) + if (!number_of_iterations_exit (loop, exit, niter)) { if (dump_file && (dump_flags & TDF_DETAILS)) fprintf (dump_file, " FAILED: number of iterations not known\n"); diff --git a/gcc/tree-scalar-evolution.c b/gcc/tree-scalar-evolution.c index d8ed84a..a5c8360 100644 --- a/gcc/tree-scalar-evolution.c +++ b/gcc/tree-scalar-evolution.c @@ -3076,7 +3076,7 @@ number_of_latch_executions (struct loop *loop) res = chrec_dont_know; exit = single_exit (loop); - if (exit && number_of_iterations_exit (loop, exit, &niter_desc, false)) + if (exit && number_of_iterations_exit (loop, exit, &niter_desc)) { may_be_zero = niter_desc.may_be_zero; res = niter_desc.niter; diff --git a/gcc/tree-ssa-loop-ivcanon.c b/gcc/tree-ssa-loop-ivcanon.c index 76ecba4..595fc92 100644 --- a/gcc/tree-ssa-loop-ivcanon.c +++ b/gcc/tree-ssa-loop-ivcanon.c @@ -571,8 +571,7 @@ remove_redundant_iv_tests (struct loop *loop) /* Only when we know the actual number of iterations, not just a bound, we can remove the exit. */ - if (!number_of_iterations_exit (loop, exit_edge, - &niter, false, false) + if (!number_of_iterations_exit (loop, exit_edge, &niter, false) || !integer_onep (niter.assumptions) || !integer_zerop (niter.may_be_zero) || !niter.niter diff --git a/gcc/tree-ssa-loop-ivopts.c b/gcc/tree-ssa-loop-ivopts.c index f5f6e78..59a78c9 100644 --- a/gcc/tree-ssa-loop-ivopts.c +++ b/gcc/tree-ssa-loop-ivopts.c @@ -1019,9 +1019,8 @@ niter_for_exit (struct ivopts_data *data, edge exit) names that appear in phi nodes on abnormal edges, so that we do not create overlapping life ranges for them (PR 27283). */ desc = XNEW (struct tree_niter_desc); - if (!number_of_iterations_exit (data->current_loop, - exit, desc, true) - || contains_abnormal_ssa_name_p (desc->niter)) + if (!number_of_iterations_exit (data->current_loop, exit, desc) + || contains_abnormal_ssa_name_p (desc->niter)) { XDELETE (desc); desc = NULL; diff --git a/gcc/tree-ssa-loop-manip.c b/gcc/tree-ssa-loop-manip.c index e87d290..b18686b 100644 --- a/gcc/tree-ssa-loop-manip.c +++ b/gcc/tree-ssa-loop-manip.c @@ -933,7 +933,7 @@ can_unroll_loop_p (struct loop *loop, unsigned factor, if (!exit) return false; - if (!number_of_iterations_exit (loop, exit, niter, false) + if (!number_of_iterations_exit (loop, exit, niter) || niter->cmp == ERROR_MARK /* Scalar evolutions analysis might have copy propagated the abnormal ssa names into these expressions, hence diff --git a/gcc/tree-ssa-loop-niter.c b/gcc/tree-ssa-loop-niter.c index 5bc1c00..f2a436f 100644 --- a/gcc/tree-ssa-loop-niter.c +++ b/gcc/tree-ssa-loop-niter.c @@ -2322,7 +2322,7 @@ number_of_iterations_exit_assumptions (struct loop *loop, edge exit, bool number_of_iterations_exit (struct loop *loop, edge exit, struct tree_niter_desc *niter, - bool, bool every_iteration) + bool every_iteration) { if (!number_of_iterations_exit_assumptions (loop, exit, niter, every_iteration)) @@ -2348,7 +2348,7 @@ find_loop_niter (struct loop *loop, edge *exit) *exit = NULL; FOR_EACH_VEC_ELT (exits, i, ex) { - if (!number_of_iterations_exit (loop, ex, &desc, false)) + if (!number_of_iterations_exit (loop, ex, &desc)) continue; if (integer_nonzerop (desc.may_be_zero)) @@ -2404,8 +2404,6 @@ finite_loop_p (struct loop *loop) widest_int nit; int flags; - if (flag_unsafe_loop_optimizations) - return true; flags = flags_from_decl_or_type (current_function_decl); if ((flags & (ECF_CONST|ECF_PURE)) && !(flags & ECF_LOOPING_CONST_OR_PURE)) { @@ -3751,7 +3749,7 @@ estimate_numbers_of_iterations_loop (struct loop *loop) likely_exit = single_likely_exit (loop); FOR_EACH_VEC_ELT (exits, i, ex) { - if (!number_of_iterations_exit (loop, ex, &niter_desc, false, false)) + if (!number_of_iterations_exit (loop, ex, &niter_desc, false)) continue; niter = niter_desc.niter; diff --git a/gcc/tree-ssa-loop-niter.h b/gcc/tree-ssa-loop-niter.h index 1aea580..dd672bd 100644 --- a/gcc/tree-ssa-loop-niter.h +++ b/gcc/tree-ssa-loop-niter.h @@ -25,7 +25,7 @@ extern tree simplify_using_initial_conditions (struct loop *, tree, tree = NULL); extern bool loop_only_exit_p (const struct loop *, const_edge); extern bool number_of_iterations_exit (struct loop *, edge, - struct tree_niter_desc *niter, bool, + struct tree_niter_desc *niter, bool every_iteration = true); extern bool number_of_iterations_exit_assumptions (struct loop *, edge, struct tree_niter_desc *,