*PING* [PATCH] fortran: Remove useless nested end of scalarization chain handling
Ping:
https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
Maybe I could argue that I can self approve, as the patch is a partial
revert an old patch of mine:
https://gcc.gnu.org/r180889
Le 07/07/2024 à 11:00, Mikael Morin a écrit :
Hello,
this is another small cleanup I had lying around.
Regression-tested on x86_64-linux. Ok for master?
-- 8< --
Remove the special handling of end of nested scalarization chains, which
advanced the chain to an element of a parent chain when the current one
was reaching its end.
That handling was superfluous as nested chains correspond to nested
scalarizations of subexpressions and the scalarizations don't extend beyond
their associated subexpression and don't use any scalarisation element from
the parent expression.
No change of behaviour, as the GFC_SE struct is supposed to be in its final
state anyway when the last element from the chain has been consumed.
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_advance_se_ss_chain): Don't use an element
from the parent scalarization chain when the current chain reaches
its end.
---
gcc/fortran/trans-expr.cc | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 477c2720187..f0862db5f17 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -2052,7 +2052,6 @@ void
gfc_advance_se_ss_chain (gfc_se * se)
{
gfc_se *p;
- gfc_ss *ss;
gcc_assert (se != NULL && se->ss != NULL && se->ss != gfc_ss_terminator);
@@ -2064,15 +2063,7 @@ gfc_advance_se_ss_chain (gfc_se * se)
gcc_assert (p->parent == NULL || p->parent->ss == p->ss
|| p->parent->ss->nested_ss == p->ss);
- /* If we were in a nested loop, the next scalarized expression can be
-on the parent ss' next pointer. Thus we should not take the next
-pointer blindly, but rather go up one nest level as long as next
-is the end of chain. */
- ss = p->ss;
- while (ss->next == gfc_ss_terminator && ss->parent != NULL)
- ss = ss->parent;
-
- p->ss = ss->next;
+ p->ss = p->ss->next;
p = p->parent;
}
*PING* [PATCH v3 10/10] fortran: Add -finline-intrinsics flag for MINLOC/MAXLOC [PR90608]
*PING*
Joseph, could you take a quick look at the handling of the new option?
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html
Le 23/08/2024 à 10:31, Mikael Morin a écrit :
From: Mikael Morin
The documentation in this patch was partly reworded, compared
to the previous version posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660607.html
The rest of the patch is unchanged, just rebased to a more recent
master.
Joseph is in CC as I need a ack for the new option.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Introduce the -finline-intrinsics flag to control from the command line
whether to generate either inline code or calls to the functions from the
library, for the MINLOC and MAXLOC intrinsics.
The flag allows to specify inlining either independently for each intrinsic
(either MINLOC or MAXLOC), or all together. For each intrinsic, a default
value is set if none was set. The default value depends on the optimization
setting: inlining is avoided if not optimizing or if optimizing for size;
otherwise inlining is preferred.
There is no direct support for this behaviour provided by the .opt options
framework. It is obtained by defining three different variants of the flag
(finline-intrinsics, fno-inline-intrinsics, finline-intrinsics=) all using
the same underlying option variable. Each enum value (corresponding to an
intrinsic function) uses two identical bits, and the variable is initialized
with alternated bits, so that we can tell whether the value was set or not
by checking whether the two bits have different values.
PR fortran/90608
gcc/ChangeLog:
* flag-types.h (enum gfc_inlineable_intrinsics): New type.
gcc/fortran/ChangeLog:
* invoke.texi(finline-intrinsics): Document new flag.
* lang.opt (finline-intrinsics, finline-intrinsics=,
fno-inline-intrinsics): New flags.
* options.cc (gfc_post_options): If the option variable controling
the inlining of MAXLOC (respectively MINLOC) has not been set, set
it or clear it depending on the optimization option variables.
* trans-intrinsic.cc (gfc_inline_intrinsic_function_p): Return false
if inlining for the intrinsic is disabled according to the option
variable.
gcc/testsuite/ChangeLog:
* gfortran.dg/minmaxloc_18.f90: New test.
* gfortran.dg/minmaxloc_18a.f90: New test.
* gfortran.dg/minmaxloc_18b.f90: New test.
* gfortran.dg/minmaxloc_18c.f90: New test.
* gfortran.dg/minmaxloc_18d.f90: New test.
---
gcc/flag-types.h| 30 +
gcc/fortran/invoke.texi | 31 +
gcc/fortran/lang.opt| 27 +
gcc/fortran/options.cc | 21 +-
gcc/fortran/trans-intrinsic.cc | 13 +-
gcc/testsuite/gfortran.dg/minmaxloc_18.f90 | 772
gcc/testsuite/gfortran.dg/minmaxloc_18a.f90 | 10 +
gcc/testsuite/gfortran.dg/minmaxloc_18b.f90 | 10 +
gcc/testsuite/gfortran.dg/minmaxloc_18c.f90 | 10 +
gcc/testsuite/gfortran.dg/minmaxloc_18d.f90 | 10 +
10 files changed, 929 insertions(+), 5 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18.f90
create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18a.f90
create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18b.f90
create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18c.f90
create mode 100644 gcc/testsuite/gfortran.dg/minmaxloc_18d.f90
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 1e497f0bb91..df56337f7e8 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -451,6 +451,36 @@ enum gfc_convert
};
+/* gfortran -finline-intrinsics= values;
+ We use two identical bits for each value, and initialize with alternated
+ bits, so that we can check whether a value has been set by checking whether
+ the two bits have identical value. */
+
+#define GFC_INL_INTR_VAL(idx) (3 << (2 * idx))
+#define GFC_INL_INTR_UNSET_VAL(val) (0x & (val))
+
+enum gfc_inlineable_intrinsics
+{
+ GFC_FLAG_INLINE_INTRINSIC_NONE = 0,
+ GFC_FLAG_INLINE_INTRINSIC_MAXLOC = GFC_INL_INTR_VAL (0),
+ GFC_FLAG_INLINE_INTRINSIC_MINLOC = GFC_INL_INTR_VAL (1),
+ GFC_FLAG_INLINE_INTRINSIC_ALL = GFC_FLAG_INLINE_INTRINSIC_MAXLOC
+ | GFC_FLAG_INLINE_INTRINSIC_MINLOC,
+
+ GFC_FLAG_INLINE_INTRINSIC_NONE_UNSET
+ = GFC_INL_INTR_UNSET_VAL (GFC_FLAG_INLINE_INTRINSIC_NONE),
+ GFC_FLAG_INLINE_INTRINSIC_MAXLOC_UNSET
+ = GFC_INL_INTR_UNSET_VAL (GFC_FLAG_INLINE_INTRINSIC_MAXLOC),
+ GFC_FLAG_INLINE_INTRINSIC_MINLOC_UNSET
+ = GFC_INL_INTR_UNSET_VAL (GFC_FLAG_INLINE_INTRINSIC_MINLOC),
+ GFC_FLAG_INLINE_INTRINSIC_ALL_UNSET
+ = GFC_INL_INTR_UNSET_VAL (GFC_FLAG_INLINE_INTRINSIC_ALL)
+};
+
+#undef GFC_INL_INTR_UNSET_VAL
+#undef GFC_INL_INTR_VAL
+
+
/* Inline String Operations functions. */
enum ilsop_fn
Re: *PING* [PATCH] fortran: Remove useless nested end of scalarization chain handling
OK. Sorry about dropping the balli on a review.
I thought it had already been approved and committed.
--
steve
On Fri, Sep 13, 2024 at 12:19:48PM +0200, Mikael Morin wrote:
> Ping:
>
> https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
>
> Maybe I could argue that I can self approve, as the patch is a partial
> revert an old patch of mine:
>
> https://gcc.gnu.org/r180889
>
> Le 07/07/2024 à 11:00, Mikael Morin a écrit :
> > Hello,
> >
> > this is another small cleanup I had lying around.
> > Regression-tested on x86_64-linux. Ok for master?
> >
> > -- 8< --
> >
> > Remove the special handling of end of nested scalarization chains, which
> > advanced the chain to an element of a parent chain when the current one
> > was reaching its end.
> >
> > That handling was superfluous as nested chains correspond to nested
> > scalarizations of subexpressions and the scalarizations don't extend beyond
> > their associated subexpression and don't use any scalarisation element from
> > the parent expression.
> >
> > No change of behaviour, as the GFC_SE struct is supposed to be in its final
> > state anyway when the last element from the chain has been consumed.
> >
> > gcc/fortran/ChangeLog:
> >
> > * trans-expr.cc (gfc_advance_se_ss_chain): Don't use an element
> > from the parent scalarization chain when the current chain reaches
> > its end.
> > ---
> > gcc/fortran/trans-expr.cc | 11 +--
> > 1 file changed, 1 insertion(+), 10 deletions(-)
> >
> > diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> > index 477c2720187..f0862db5f17 100644
> > --- a/gcc/fortran/trans-expr.cc
> > +++ b/gcc/fortran/trans-expr.cc
> > @@ -2052,7 +2052,6 @@ void
> > gfc_advance_se_ss_chain (gfc_se * se)
> > {
> > gfc_se *p;
> > - gfc_ss *ss;
> > gcc_assert (se != NULL && se->ss != NULL && se->ss !=
> > gfc_ss_terminator);
> > @@ -2064,15 +2063,7 @@ gfc_advance_se_ss_chain (gfc_se * se)
> > gcc_assert (p->parent == NULL || p->parent->ss == p->ss
> > || p->parent->ss->nested_ss == p->ss);
> > - /* If we were in a nested loop, the next scalarized expression can be
> > -on the parent ss' next pointer. Thus we should not take the next
> > -pointer blindly, but rather go up one nest level as long as next
> > -is the end of chain. */
> > - ss = p->ss;
> > - while (ss->next == gfc_ss_terminator && ss->parent != NULL)
> > - ss = ss->parent;
> > -
> > - p->ss = ss->next;
> > + p->ss = p->ss->next;
> > p = p->parent;
> > }
--
Steve
