[pushed] testsuite: add additional option to force DSE execution [PR103662]
Commit Message
I have just pushed the attached fix for two UNRESOLVED checks at
-O0 that I hadn’t seen.
Comments
On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
> hadn’t seen.
I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?
Even better would be to check that the z._data = stores are both present
in *.optimized dump, but that doesn't really work at -O2 or above because
we inline the functions and optimize it completely away (both the stores
and corresponding reads).
The first hunk is needed so that __OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.
2022-04-25 Jakub Jelinek <jakub@redhat.com>
PR fortran/103662
* lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
a var definition to avoid pedwarn about empty translation unit.
* gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
dg-additional-options, guard scan-tree-dump-not directives on
__OPTIMIZE__ target.
--- gcc/testsuite/lib/target-supports.exp.jj 2022-04-22 13:36:56.150960826 +0200
+++ gcc/testsuite/lib/target-supports.exp 2022-04-25 14:06:21.620537483 +0200
@@ -11770,6 +11770,7 @@ proc check_effective_target___OPTIMIZE__
#ifndef __OPTIMIZE__
# error nein
#endif
+ int optimize;
} [current_compiler_flags]]
}
--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03.jj 2022-04-25 13:54:38.320309119 +0200
+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 2022-04-25 14:04:01.346486431 +0200
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
+! { dg-additional-options "-fdump-tree-dse-details" }
!
! Check that pointer assignments allowed by F2003:C717
! work and check null initialization of CLASS(*) pointers.
@@ -71,5 +71,5 @@ end subroutine foo_sq
! We used to produce multiple independant types for the unlimited polymorphic
! descriptors (types for class(*)) which caused stores to them to be seen as
! useless.
-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" } }
-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" } }
+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" { target __OPTIMIZE__ } } }
+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" { target __OPTIMIZE__ } } }
Jakub
Le 25/04/2022 à 14:12, Jakub Jelinek a écrit :
> On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
>> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
>> hadn’t seen.
>
> I don't like forcing of DSE in -O0 compilation, wouldn't it be better
> to just not check the dse dump at -O0 like in the following patch?
>
Certainly better. I actually looked for something alike already
existing before trying to write a conditional in the dg-final code and
finally deciding to go the easy way.
> Even better would be to check that the z._data = stores are both present
> in *.optimized dump, but that doesn't really work at -O2 or above because
> we inline the functions and optimize it completely away (both the stores
> and corresponding reads).
>
Yes, and global optimization is already checked by test execution anyway.
> The first hunk is needed so that __OPTIMIZE__ effective target works in
> Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
> is considered not to match at all.
>
Maybe worth putting as code comment.
OK from my side, thanks.
On 25 April 2022 14:12:30 CEST, Jakub Jelinek via Fortran <fortran@gcc.gnu.org> wrote:
>On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
>> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
>> hadn’t seen.
>
>I don't like forcing of DSE in -O0 compilation, wouldn't it be better
>to just not check the dse dump at -O0 like in the following patch?
As Mikael already said, that's preferable indeed.
>
>Even better would be to check that the z._data = stores are both present
>in *.optimized dump, but that doesn't really work at -O2 or above because
>we inline the functions and optimize it completely away (both the stores
>and corresponding reads).
>
>The first hunk is needed so that __OPTIMIZE__ effective target works in
>Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
>is considered not to match at all.
>
>2022-04-25 Jakub Jelinek <jakub@redhat.com>
>
> PR fortran/103662
> * lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
> a var definition to avoid pedwarn about empty translation unit.
> * gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
> dg-additional-options, guard scan-tree-dump-not directives on
> __OPTIMIZE__ target.
>
>--- gcc/testsuite/lib/target-supports.exp.jj 2022-04-22 13:36:56.150960826 +0200
>+++ gcc/testsuite/lib/target-supports.exp 2022-04-25 14:06:21.620537483 +0200
>@@ -11770,6 +11770,7 @@ proc check_effective_target___OPTIMIZE__
> #ifndef __OPTIMIZE__
> # error nein
Hmz. I _think_ that was /me and reading it again now, we should should not bluntly say nein but more something like
unwilling to ignore __OPTIMIZE__, dude
or anything more descriptive and universally understandably I assume.
> #endif
>+ int optimize;
a plain ; won't cut it. int dummy, maybe though. There is probably a lot more of these, aren't there?
thanks,
> } [current_compiler_flags]]
> }
>
>--- gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03.jj 2022-04-25 13:54:38.320309119 +0200
>+++ gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 2022-04-25 14:04:01.346486431 +0200
>@@ -1,5 +1,5 @@
> ! { dg-do run }
>-! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
>+! { dg-additional-options "-fdump-tree-dse-details" }
> !
> ! Check that pointer assignments allowed by F2003:C717
> ! work and check null initialization of CLASS(*) pointers.
>@@ -71,5 +71,5 @@ end subroutine foo_sq
> ! We used to produce multiple independant types for the unlimited polymorphic
> ! descriptors (types for class(*)) which caused stores to them to be seen as
> ! useless.
>-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" } }
>-! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" } }
>+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &w" "dse1" { target __OPTIMIZE__ } } }
>+! { dg-final { scan-tree-dump-not "Deleted dead store: z._data = &x" "dse1" { target __OPTIMIZE__ } } }
>
>
> Jakub
>
From 6cc26f3037a18b9a958b4ac2a1363149a7fccd39 Mon Sep 17 00:00:00 2001
From: Mikael Morin <mikael@gcc.gnu.org>
Date: Mon, 25 Apr 2022 13:14:20 +0200
Subject: [pushed] =?UTF-8?q?testsuite:=C2=A0add=20additional=20option=20to?=
=?UTF-8?q?=20force=20DSE=20execution=20[PR103662]?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This fixes a dump tree match check that is UNRESOLVED with the -O0
optimization option, as the optimization pass corresponding to the
dump file is not run at -O0, and the dump is not generated.
PR fortran/103662
gcc/testsuite/ChangeLog:
* gfortran.dg/unlimited_polymorphic_3.f03: Force execution of
the DSE optimization pass.
---
gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-additional-options "-fdump-tree-dse-details" }
+! { dg-additional-options "-ftree-dse -fdump-tree-dse-details" }
!
! Check that pointer assignments allowed by F2003:C717
! work and check null initialization of CLASS(*) pointers.
--
2.35.1