| Message ID | 20161213092829.GA12324@linux.vnet.ibm.com |
|---|---|
| State | New |
| Headers | show |
On Tue, Dec 13, 2016 at 10:28:29AM +0100, Dominik Vogt wrote: > The attached patch fixes an md test execution problem on S/390. > The tests would be built with -march=z13 but executed even on > older machines. Build with -march=native instead, so executing > the tests should work on any machine generation. > > Tested on s390x biarch, but not bootstrapped or regression tested. I think this isn't a very good idea. Then the testresults from one box to another one will mean something different. IMHO you want something like x86 avx_runtime effective target (z13_runtime?), which would stand for running on z13 capable hw and with z13 assembler support. Or choose what options to include based on such effective target tests, and perhaps also select a default action, like we do on some targets e.g. in the vectorizer. Some tests are dg-do run by default if the hw supports the needed ISA, or dg-do assemble, if the hw doesn't support that, but at least the assembler can assemble those, otherwise dg-do compile or something similar. With -march=native, you find some results in gcc-testresults and the exact underlying hw will be part of the needed info to see what you've actually tested. While usually just some tests are UNSUPPORTED if hw or assembler doesn't have the needed features. Jakub
On Tue, Dec 13, 2016 at 10:42:37AM +0100, Jakub Jelinek wrote: > On Tue, Dec 13, 2016 at 10:28:29AM +0100, Dominik Vogt wrote: > > The attached patch fixes an md test execution problem on S/390. > > The tests would be built with -march=z13 but executed even on > > older machines. Build with -march=native instead, so executing > > the tests should work on any machine generation. > > > > Tested on s390x biarch, but not bootstrapped or regression tested. > > I think this isn't a very good idea. Then the testresults from one > box to another one will mean something different. Note that this is already the case: Recently the setmem-long-1.c test case has started crashing on zEC12 because -march=z13 now generates z13 specific instructions. > IMHO you want something like x86 avx_runtime effective target > (z13_runtime?), which would stand for running on z13 capable hw and > with z13 assembler support. Something like that, yes, but it's not so easy because the kernel has to support it too. Some features are disabled in a VM although the hardware supports them. What we really need is Run test if the test system (not just the hardware) supports the instruction set of the -march= option the test was compiled with, otherwise just compile it. I.e. derive the "effective_targt..." option from the "-march=..." option set by the torture test. > Or choose what options to include based on such effective target tests, > and perhaps also select a default action, like we do on some targets e.g. in > the vectorizer. Can you give an example test file, please? > Some tests are dg-do run by default if the hw supports > the needed ISA, or dg-do assemble, if the hw doesn't support that, but > at least the assembler can assemble those, otherwise dg-do compile or > something similar. > > With -march=native, you find some results in gcc-testresults and the exact > underlying hw will be part of the needed info to see what you've actually > tested. While usually just some tests are UNSUPPORTED if hw or assembler > doesn't have the needed features. Yes. Ciao Dominik ^_^ ^_^
On Tue, Dec 13, 2016 at 11:18:31AM +0100, Dominik Vogt wrote: > > IMHO you want something like x86 avx_runtime effective target > > (z13_runtime?), which would stand for running on z13 capable hw and > > with z13 assembler support. > > Something like that, yes, but it's not so easy because the kernel > has to support it too. Some features are disabled in a VM > although the hardware supports them. What we really need is The z13_runtime or whatever effective target routine can always just try to compile/link a simple testcase with at least one z13 specific instruction and try to run it. > Run test if the test system (not just the hardware) supports the > instruction set of the -march= option the test was compiled > with, otherwise just compile it. > > I.e. derive the "effective_targt..." option from the "-march=..." > option set by the torture test. > > > Or choose what options to include based on such effective target tests, > > and perhaps also select a default action, like we do on some targets e.g. in > > the vectorizer. > > Can you give an example test file, please? Look e.g. at gcc.dg/vect/vect.exp and testsuite/lib/*.exp for dg-do-what-default and the games done with it. E.g. if you set (and saved/restored) in addition to dg-do-what-default also EFFECTIVE_TARGETS then perhaps you could use et-dg-runtest or similar. Jakub
On Tue, Dec 13, 2016 at 11:42:40AM +0100, Jakub Jelinek wrote: > On Tue, Dec 13, 2016 at 11:18:31AM +0100, Dominik Vogt wrote: > > > IMHO you want something like x86 avx_runtime effective target > > > (z13_runtime?), which would stand for running on z13 capable hw and > > > with z13 assembler support. > > > > Something like that, yes, but it's not so easy because the kernel > > has to support it too. Some features are disabled in a VM > > although the hardware supports them. What we really need is > > The z13_runtime or whatever effective target routine can always > just try to compile/link a simple testcase with at least one z13 specific > instruction and try to run it. > > > Run test if the test system (not just the hardware) supports the > > instruction set of the -march= option the test was compiled > > with, otherwise just compile it. > > > > I.e. derive the "effective_targt..." option from the "-march=..." > > option set by the torture test. > > > > > Or choose what options to include based on such effective target tests, > > > and perhaps also select a default action, like we do on some targets e.g. in > > > the vectorizer. > > > > Can you give an example test file, please? > > Look e.g. at gcc.dg/vect/vect.exp and testsuite/lib/*.exp for > dg-do-what-default and the games done with it. E.g. if you set > (and saved/restored) in addition to dg-do-what-default also EFFECTIVE_TARGETS > then perhaps you could use et-dg-runtest or similar. Thanks. New patch with different approach here: https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01621.html Ciao Dominik ^_^ ^_^
diff --git a/gcc/testsuite/gcc.target/s390/s390.exp b/gcc/testsuite/gcc.target/s390/s390.exp index 450dcaf..9393478 100644 --- a/gcc/testsuite/gcc.target/s390/s390.exp +++ b/gcc/testsuite/gcc.target/s390/s390.exp @@ -112,11 +112,11 @@ torture-finish # Additional md torture tests. torture-init set MD_TEST_OPTS [list \ - {-Os -march=z900} {-Os -march=z13} \ - {-O0 -march=z900} {-O0 -march=z13} \ - {-O1 -march=z900} {-O1 -march=z13} \ - {-O2 -march=z900} {-O2 -march=z13} \ - {-O3 -march=z900} {-O3 -march=z13}] + {-Os -march=z900} {-Os -march=native} \ + {-O0 -march=z900} {-O0 -march=native} \ + {-O1 -march=z900} {-O1 -march=native} \ + {-O2 -march=z900} {-O2 -march=native} \ + {-O3 -march=z900} {-O3 -march=native}] set-torture-options $MD_TEST_OPTS gcc-dg-runtest [lsort [glob -nocomplain $md_tests]] "" $DEFAULT_CFLAGS torture-finish