public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/102905] [12 regression] several vector test cases fail on power 7 after r12-4490
Date: Mon, 25 Oct 2021 09:33:05 +0000	[thread overview]
Message-ID: <bug-102905-4-ipvcMtsd15@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-102905-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102905

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, so with a cc1 cross to powerpc64-linux and -mcpu=power7 I do see the
correct things in the dump files (but not without -mcpu=power7).  Similar
behavior
is for -mvsx vs. -mno-vsx (where it also reproduces on ppc64le)

In the failing case we ask the target

rs6000_builtin_support_vector_misalignment (mode=E_V4SImode, 
    type=<integer_type 0x7ffff6546738 int>, misalignment=8, is_packed=false)

(that's the store)

but w/o TARGET_VSX that function simply returns false.

The source of the testcase (vect-peel-1.c) specifically says

  /* All the accesses are misaligned. With cost model disabled, we
     count the number of aligned accesses for each peeling option, and
     in this case we align the two loads if possible (i.e., if
     misaligned stores are supported).  */
  for (i = 1; i <= N; i++)
    {
      ia[i] = ib[i+2] + ib[i+6];

and that's what seems to happen.  But then the testcase has

/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect"
{ target { { vect_element_align } && { vect_aligned_arrays } } xfail { !
vect_unaligned_possible } } } } */
/* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
1 "vect" { xfail vect_element_align_preferred } } } */

so it expects to peel, vectorize the loop but also not vectorize an unaligned
accesss?

Ah, so before the change we peeled 3 iterations, aligning the store which
means we were able to use re-aligning loads.  But now we are peeling 1
iteration to align the loads (as the testcase expected).

And the key difference is that we're now invoking the target hook to tell
whether vect_peeling_hash_insert should boost the entry but formerly
we used vect_supportable_dr_alignment which had the re-align load path.
But after later refactoring we can now again easily use
vect_supportable_dr_alignment here.

  parent reply	other threads:[~2021-10-25  9:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-22 18:56 [Bug testsuite/102905] New: " seurer at gcc dot gnu.org
2021-10-22 21:20 ` [Bug testsuite/102905] " pinskia at gcc dot gnu.org
2021-10-25  6:40 ` [Bug tree-optimization/102905] " rguenth at gcc dot gnu.org
2021-10-25  9:33 ` rguenth at gcc dot gnu.org [this message]
2021-10-25 10:49 ` cvs-commit at gcc dot gnu.org
2021-10-25 10:49 ` rguenth at gcc dot gnu.org

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=bug-102905-4-ipvcMtsd15@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@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).