public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hp@bitrange.com>
To: gcc-patches@gcc.gnu.org
Subject: gcc.dg/pr30957-1.c: xfail for mmix.
Date: Sat, 8 Aug 2020 20:07:01 -0400 (EDT)	[thread overview]
Message-ID: <alpine.BSF.2.20.16.2008082006200.90012@arjuna.pair.com> (raw)

Committed.

IV (loop2_unroll) doesn't like the mmix port.  The feelings are mutual.

For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:

- IV doesn't handle the zero-extension-by-shift sequences generated by
  middle-end (expr.c:convert_mode_scalar) in the absence of
  zero-extend patterns in a port.

- (when adding such patterns)
  IV doesn't understand the subreg constructs generated by middle-end
  in the absence of addsi3 and compare/branch in SImode (int).

- (when hacking pr30957-1.c to iterate using a register-mode type)
  IV doesn't understand the admittedly weird SFmode operations
  (performing in DFmode, then truncating, for lack of SFmode
  operations, but presence of truncdfsf2 and float_extendsfdf2) in
  order to perform the "Expanding Accumulator" optimization.  When
  also editing the type in the test to be double instead of float, the
  test passes.

While at least the last point seems like a valid reason to just skip
the test for mmix, it also seems possible that IV (and maybe
convert_mode_scalar by e.g. adding REG_EQUIV notes) be improved to be
both smarter and dumber to actually make the test pass, so I think
it's better to use xfail.  Smarter: understanding zero-extend-
by-shift and subregged operations better, and "seeing" the
accumulation through the DF/SFmode truncations and expansions.
Dumber: ignoring the cost; unrolling the several operations per SFmode
add anyway.

I'm considering adding a variant of this test with "double" and
"__SIZE_TYPE__" iteration types, as that passes for mmix as-is.
Maybe as a mmix-specific test; the world has suffered enough from the
questionable gcc.dg/pr30957-1.c (see the test and its history).

gcc/testsuite:
	* gcc.dg/pr30957-1.c: xfail for mmix.

--- gcc/gcc/testsuite/gcc.dg/pr30957-1.c.orig	Mon Jan 13 22:30:47 2020
+++ gcc/gcc/testsuite/gcc.dg/pr30957-1.c	Sun Aug  9 00:46:12 2020
@@ -1,4 +1,4 @@
-/* { dg-do run } */
+/* { dg-do run { xfail { mmix-*-* } } } */
 /* We don't (and don't want to) perform this optimisation on soft-float targets,
    where each addition is a library call.  /
 /* { dg-require-effective-target hard_float } */
@@ -33,4 +33,4 @@ main ()
   exit (0);
 }

-/* { dg-final { scan-rtl-dump "Expanding Accumulator" "loop2_unroll" } } */
+/* { dg-final { scan-rtl-dump "Expanding Accumulator" "loop2_unroll" { xfail mmix-*-* } } } */

                 reply	other threads:[~2020-08-09  0:07 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=alpine.BSF.2.20.16.2008082006200.90012@arjuna.pair.com \
    --to=hp@bitrange.com \
    --cc=gcc-patches@gcc.gnu.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).