public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59984] OpenMP and Cilk Plus SIMD pragma makes loop incorrect
Date: Fri, 14 Nov 2014 15:04:00 -0000	[thread overview]
Message-ID: <bug-59984-4-T8OGleBWGE@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-59984-4@http.gcc.gnu.org/bugzilla/>

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
                 CC|                            |jamborm at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Assignee|jakub at gcc dot gnu.org           |unassigned at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Stupachenko Evgeny from comment #12)
> Created attachment 33963 [details]
> test case where pragma simd disable vectorization
> 
> The following test case compiled with "-Ofast" vectorize the loop in the
> GetXsum function.
> Adding "-fopenmp" leads to failed vectorization due to:
> 
> simd_issue.cpp:26:18: note: not vectorized: data ref analysis failed
> D.2329[_7].x = _12;
> 
> It looks like before the patch in this Bug loop was vectorized with -fopenmp.

The testcase is invalid, you need reduction(+:sim) clause, otherwise the loop
has invalid inter-iteration dependencies.

That said, even with that, with C it vectorizes fine, while with C++ it
doesn't.

In *.einline the C -> C++ difference is (before that I don't see such):
-  D.1856[_19].x = _24;
-  _26 = &D.1856[_19];
-  _27 = MEM[(const struct XY *)_26].x;
+  D.2352[_19].x = _24;
+  _26 = &D.2352[_19];
+  _40 = MEM[(float *)_26];

In *.ealias the C -> C++ difference is:
-  D.1856[_19].x = _24;
-  _27 = MEM[(const struct XY *)&D.1856][_19].x;
+  D.2352[_19].x = _24;
+  _26 = &D.2352[_19];
+  _40 = MEM[(float *)_26];

and apparently FRE1 handles the former but not the latter.  Richard?
As the struct contains float at that offset, I don't see why FRE1 shouldn't
optimize that to _40 = _24.

Shorter testcase for the FRE1 missed-optimization:
struct S { float a, b; };

float
foo (int x, float y)
{
  struct S z[1024];
  z[x].a = y;
  struct S *p = &z[x];
  float *q = (float *) p;
  return *q;
}

(dunno why the inliner handles things differently between C and C++ on the #c12
testcase).  Now, as for vectorizing it even if FRE isn't able to optimize it,
we currently don't support interleaved accesses to the "omp simd array"
attributed arrays, perhaps we could at least some easy cases thereof, and
supposedly we should teach SRA about those too (like, if the arrays aren't
addressable and aren't accesses as whole, but just individual fields, split it
into separate "omp simd array" accesses instead.  In this particular case due
to the FRE missed optimization it is addressable though.
Or perhaps teach fold to gimple folding to fold that:
  q_5 = &z[x_2(D)];
  _6 = *q_5;
back into:
  _6 = z[x_2(D)].x;
?


  parent reply	other threads:[~2014-11-14 15:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-29 14:41 [Bug c/59984] New: " evstupac at gmail dot com
2014-01-29 14:42 ` [Bug c/59984] " evstupac at gmail dot com
2014-02-05 18:42 ` mpolacek at gcc dot gnu.org
2014-02-06 12:59 ` izamyatin at gmail dot com
2014-02-06 16:11 ` jakub at gcc dot gnu.org
2014-02-07 14:34 ` jakub at gcc dot gnu.org
2014-02-07 15:20 ` jakub at gcc dot gnu.org
2014-02-08  9:10 ` jakub at gcc dot gnu.org
2014-02-08  9:29 ` jakub at gcc dot gnu.org
2014-02-08  9:30 ` jakub at gcc dot gnu.org
2014-04-22 11:38 ` jakub at gcc dot gnu.org
2014-07-16 13:31 ` jakub at gcc dot gnu.org
2014-10-30 10:43 ` jakub at gcc dot gnu.org
2014-11-13 23:51 ` evstupac at gmail dot com
2014-11-14 15:04 ` jakub at gcc dot gnu.org [this message]
2014-11-17  9:03 ` rguenther at suse dot de
2014-11-17 14:58 ` rguenth at gcc dot gnu.org
2015-06-26 20:13 ` jakub at gcc dot gnu.org
2015-06-26 20:36 ` jakub 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-59984-4-T8OGleBWGE@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).