public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Stubbs, Andrew" <Andrew_Stubbs@mentor.com>
To: Jakub Jelinek <jakub@redhat.com>, "gcc@gcc.gnu.org" <gcc@gcc.gnu.org>
Subject: OpenMP auto-simd
Date: Wed, 2 Mar 2022 15:12:30 +0000	[thread overview]
Message-ID: <2213264c2c5c467fb491f71051173873@svr-ies-mbx-01.mgc.mentorg.com> (raw)

Hi Jakub, all,

Has anyone ever considered having GCC add the "simd" clause to offload (or regular) loop nests automatically?

For example, something like "-fomp-auto-simd" would transform "distribute parallel" to "distribute parallel simd" automatically. Loop nests that already contain "simd" clauses or directives would remain unchanged, most likely.

The reason I ask is that other toolchains have chosen to use a "SIMT" model for GPUs, which means that OpenMP threads map to individual vector lanes and are therefore are strictly scalar. The result is that the "simd" directive is irrelevant and lots of code out there isn't using it at all (so I'm told). Meanwhile, in GCC we map OpenMP threads to Nvidia warps and AMD GCN wavefronts, so it is impossible to get full performance without explicitly specifying the "simd" directive. We therefore suffer in direct comparisons.

I'm of the opinion that GCC is the one implementing OpenMP as intended, but all the same I need to explore our options here, figure out what the consequences would be, and plan a project to do what we can.

I've thought of simply enabling "-ftree-vectorize" on AMD GCN (this doesn't help NVPTX) but I think that is sub-optimal because things like the OpenMP scheduler really need to be aware of the vector size, and there's probably other ways in which parallel regions can be better formed with regard to the vectorizer. If these features don't exist right now then I have an opportunity to include them in our upcoming project.

Any info/suggestions/advice would be appreciated.

Thanks

Andrew

             reply	other threads:[~2022-03-02 15:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02 15:12 Stubbs, Andrew [this message]
2022-03-02 15:24 ` Jakub Jelinek
2022-03-02 16:11   ` Stubbs, Andrew
2022-03-08 14:29 ` Thomas Schwinge
2022-03-08 16:47   ` Stubbs, Andrew

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=2213264c2c5c467fb491f71051173873@svr-ies-mbx-01.mgc.mentorg.com \
    --to=andrew_stubbs@mentor.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /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).