Message ID | 5d85fc5c-8e06-8568-43e5-6b9273f86a76@orange.fr |
---|---|
State | New |
Headers | show |
Series | [pushed] testsuite: add additional option to force DSE execution [PR103662] | expand |
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(-) diff --git a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 index 780d68cdd87..4104de6ac68 100644 --- a/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 +++ b/gcc/testsuite/gfortran.dg/unlimited_polymorphic_3.f03 @@ -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