Re: [Patch, Fortran] PR 57160: short-circuit IF only with -ffrontend-optimize

[Fritz Reese <fritzoreese at gmail dot com>]

On Mon, Jul 23, 2018 at 1:11 PM Janus Weil <janus@gcc.gnu.org> wrote:
>
> Hi Adam,
>
> 2018-07-23 9:40 GMT+02:00 Adam Hirst <adam@aphirst.karoo.co.uk>:
[...]
> > One thing I'm not seeing in the original discussion was whether or not
> > this should also count for -Og
>
> good point!
>
>
> > which certainly in my experience is
> > (paired with -g) a common debug setting.
>
> Agreed. I actually use it myself.
>
>
> > I would err towards -Og here being paired with -O0, but I could see it
> > being argued both ways - either way, I thought it might at least be
> > worth making explicit?
>
> Well, yes, the current documentation for -ffrontend-optimize is not
> horribly explicit, but it does say: " Enabled by default by any -O
> option." Technically that includes -Og, I guess.
>
> Phenomenologically, it seems that -Og indeed behaves like -O{1,2,3} in
> this respect. If one wanted to change that, one would probably do
> this:
>
> Index: gcc/fortran/options.c
> ===================================================================
> --- gcc/fortran/options.c    (revision 262908)
> +++ gcc/fortran/options.c    (working copy)
> @@ -417,7 +417,7 @@
>       specified it directly.  */
>
>    if (flag_frontend_optimize == -1)
> -    flag_frontend_optimize = optimize;
> +    flag_frontend_optimize = optimize && !optimize_debug;
>
>    /* Same for front end loop interchange.  */
>
>
> I tend to agree with you that this might be a good idea, but I also
> don't have a strong opinion here. (Alternatively one could leave
> -ffrontend-optimize as is, and just couple the short-circuiting
> behavior to "flag_frontend_optimize && !optimize_debug", but that
> seems less attractive to me.) Maybe others can comment?
>

IMO it makes sense to omit frontend optimizations with -Og since one
probably expects -g/-Og to provide the most faithful reproduction of
the code (least optimized). I would be OK including this in the patch.

> The attached patch regtests cleanly on x86_64-linux-gnu. Ok for trunk?

I would recommend updating invoke.texi to include a comment regarding
the effect of -ffrontend-optimize on short-circuiting. If you include
the above regarding -Og, you should also clarify "Enabled by default
by any -O option" (e.g. "Enabled by any -O option except -O0 and
-Og").

Normally I like to see testcase(s) enforcing the new behavior as well,
unless there is a good reason not to. (That way any future changes to
short-circuiting or -ffrontend-optimize should at least snag on the
testcase and cause special consideration.)

Otherwise looks OK.

Fritz