public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Cc: David Edelsohn <dje.gcc@gmail.com>,
	Segher Boessenkool <segher@kernel.crashing.org>
Subject: [PATCH] ppc: testsuite: test for arch_pwr7 with -mvsx in fold-vec-insert-double
Date: Mon, 11 Apr 2022 20:59:41 -0300	[thread overview]
Message-ID: <ora6cr189e.fsf@lxoliva.fsfla.org> (raw)


gcc.target/powerpc/fold-vec-insert-double.c is compiled with -mvsx,
while the expected asm output depends on target has_arch_pwr7, which
is tested for without -mvsx.

In some of our configurations, that have altivec and vsx disabled by
default, the former defines up to _ARCH_PWR7, while the latter defines
only up to _ARCH_PWR4, i.e., we compile for power7, and test for
non-power7.

This patch, admittedly ugly, enables us to test for asm output
according the actual compile target given the explicitly specified
flag.

I suppose it may be possible to turn this "magic" into a reusable proc
that sets a named variable to the result of a wrapped scan test, but
I'm not sure I'm up to the task, with the need to deal with additional
scoping, so I'm hoping this can be acceptable as is.

Tested with gcc-11 targeting ppc64-vx7r2.  Ok to install?


for  gcc/testsuite/ChangeLog

	* gcc.target/powerpc/fold-vec-insert-double.c: Test for asm
	according to the arch selected by -mvsx.
---
 .../gcc.target/powerpc/fold-vec-insert-double.c    |   48 ++++++++++++++++----
 1 file changed, 39 insertions(+), 9 deletions(-)

diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c b/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
index afd7f7e9924e8..b95f0b33d6c07 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-insert-double.c
@@ -18,21 +18,51 @@ testd_cst (double d, vector double vd)
 {
   return vec_insert (d, vd, 1);
 }
+
+/* The expected asm output varies depending on target arch_has_pwr7, but the
+   -mvsx option used for the test may implicitly enable the macro that target
+   arch_has_pwr7 tests for, while target arch_has_pwr7 doesn't take the option,
+   so we may end up compiling for one target variant and testing for another.
+   The following dejagnu magic sets $macro_is_defined to 1 or 0 depending on
+   whether ARCH_PWR7_is_defined appears in the assembly output.  */
+#ifdef _ARCH_PWR7
+int ARCH_PWR7_is_defined = 1;
+/* { dg-final { set asm_pattern_to_search_for "ARCH_PWR7_is_defined" } } */
+#endif
+
+/* { dg-final { global macro_is_defined } } */
+/* { dg-final { set macro_is_defined -1 } } */
+/* { dg-final { rename pass macro-save-pass } } */
+/* { dg-final { rename fail macro-save-fail } } */
+/* { dg-final { proc pass { args } { global macro_is_defined; set macro_is_defined 1 } } } */
+/* { dg-final { proc fail { args } { global macro_is_defined; set macro_is_defined 0 } } } */ 
+/* { dg-final { scan-assembler "$asm_pattern_to_search_for" } } */
+/* { dg-final { rename pass macro-dropme-pass } } */
+/* { dg-final { rename macro-save-pass pass } } */
+/* { dg-final { rename fail macro-dropme-fail } } */
+/* { dg-final { rename macro-save-fail fail } } */
+/* { dg-final { if { $macro_is_defined < 0 } { fail "macro detection" } } } */
+/* { dg-final { if { $macro_is_defined < 0 } { return } } } */
+
+/* { dg-final { set has_arch_pwr7 $macro_is_defined } } */
+/* This is the end of the magic.
+   We can now run tests conditionally on $has_arch_pwr7.  */
+
 /* The number of xxpermdi instructions varies between
  P7,P8,P9, ensure at least one hit. */
 /* { dg-final { scan-assembler {\mxxpermdi\M} } } */
 
 /* { dg-final { scan-assembler-times {\mrldic\M|\mrlwinm\M} 1 } } */
 
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 1 { target { ! has_arch_pwr7 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 1 { target { ! has_arch_pwr7 } } } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 1 { target { ! has_arch_pwr7 } } } } */
+/* { dg-final { if { ! $has_arch_pwr7 } { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 1 } } } */
+/* { dg-final { if { ! $has_arch_pwr7 } { scan-assembler-times {\mstfdx\M|\mstfd\M} 1 } } } */
+/* { dg-final { if { ! $has_arch_pwr7 } { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 1 } } } */
 
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 { target { has_arch_pwr7 && lp64 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { has_arch_pwr7 && lp64 } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 { target { lp64 } } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { lp64 } } } } } */
 
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target { has_arch_pwr7 && lp64 } } } } */
-/* { dg-final { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target { has_arch_pwr7 && ilp32 } } } } */
-/* { dg-final { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 { target { has_arch_pwr7 && ilp32 } } } } */
-/* { dg-final { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { has_arch_pwr7 && ilp32 } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target { lp64 } } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mlxvd2x\M|\mlxv\M|\mlvx\M} 0 { target { ilp32 } } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mstxvd2x\M|\mstxv\M|\mstvx\M} 0 { target { ilp32 } } } } } */
+/* { dg-final { if { $has_arch_pwr7 } { scan-assembler-times {\mstfdx\M|\mstfd\M} 0 { target { ilp32 } } } } } */
 

-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

             reply	other threads:[~2022-04-11 23:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-11 23:59 Alexandre Oliva [this message]
2022-04-12 18:04 ` Segher Boessenkool
2022-04-13  0:50   ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ora6cr189e.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=segher@kernel.crashing.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).