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).