public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, Nathan Sidwell <nathan@acm.org>
Subject: Re: [PATCH 3/8] nvptx -muniform-simt
Date: Mon, 13 Jun 2016 17:37:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.20.1606131910560.28650@monopod.intra.ispras.ru> (raw)
In-Reply-To: <575E2E8C.8030407@codesourcery.com>

On Sun, 12 Jun 2016, Sandra Loosemore wrote:
> On 06/09/2016 10:53 AM, Alexander Monakov wrote:
> > +@item -muniform-simt
> > +@opindex muniform-simt
> > +Generate code that allows to keep all lanes in each warp active, even when
> 
> Allows *what* to keep?  E.g. what is doing the keeping here?  If it is the
> generated code itself, please rephrase as
> 
> Generate code that keeps....

Let me try to expand and rephrase what I meant:

Allows the compiler to emit code that, at run time, may have all lanes active,
particularly in those regions of the program where observable effects from
execution must happen as if one lane is active (outside of SIMD loops).

But nevertheless generated code can run just like conventionally generated
code does: with each lane being active/inactive independently, and side
effects happening from each active lane (inside of SIMD loops).

Whether it actually runs in the former (let's call it "uniform") or the latter
("conventional") way is switchable at run time. The compiler itself is
responsible for emitting mode changes at SIMD region boundaries.

Does this help? Below I went with your suggestion, but changed "keeps" to "may
keep" because that's generally true only outside of SIMD regions.

> > +observable effects from execution should appear as if only one lane was
> 
> s/was/is/
> 
> > +active. This is achieved by instrumenting syscalls and atomic instructions
> > in
> > +a lightweight way that allows to switch behavior at runtime. This code
> 
> Same issue here....  allows *what* to switch behavior?  (And how would you
> select which run-time behavior you want?)

Sorry. This gives compiler itself a way to emit code that will switch behavior
of the subsequently running code.

> Also, in the snippet above where it is used as a noun, please
> s/runtime/run time/

Thanks. Does the following look better?

@item -muniform-simt
@opindex muniform-simt
Generate code that may keep all lanes in each warp active, even when
observable effects from execution must appear as if only one lane is active.
This is achieved by instrumenting syscalls and atomic instructions in a
lightweight way, allowing the compiler to emit code that can switch at run
time between this and conventional execution modes. This code generation
variant is used for OpenMP offloading, but the option is exposed on its own
for the purpose of testing the compiler; to generate code suitable for linking
into programs using OpenMP offloading, use option @option{-mgomp}.

Alexander

  reply	other threads:[~2016-06-13 17:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 16:54 [PATCH 0/8] NVPTX offloading to NVPTX: backend patches Alexander Monakov
2016-06-09 16:54 ` [PATCH 8/8] nvptx: handle OpenMP "omp target entrypoint" Alexander Monakov
2016-06-09 16:54 ` [PATCH 6/8] new target hook: TARGET_SIMT_VF Alexander Monakov
2016-06-09 16:54 ` [PATCH 4/8] nvptx -mgomp Alexander Monakov
2016-06-13  3:57   ` Sandra Loosemore
2016-06-09 16:54 ` [PATCH 3/8] nvptx -muniform-simt Alexander Monakov
2016-06-13  3:55   ` Sandra Loosemore
2016-06-13 17:37     ` Alexander Monakov [this message]
2016-06-22 18:39       ` Alexander Monakov
2016-06-24 20:41         ` Sandra Loosemore
2016-06-09 16:54 ` [PATCH 2/8] nvptx: implement predicated instructions Alexander Monakov
2016-06-09 16:54 ` [PATCH 1/8] nvptx -msoft-stack Alexander Monakov
2016-06-09 16:54 ` [PATCH 7/8] nvptx: new insns for OpenMP SIMD-on-SIMT Alexander Monakov
2016-06-09 16:54 ` [PATCH 5/8] nvptx mkoffload: pass -mgomp for OpenMP offloading Alexander Monakov
2016-06-09 17:00 ` [PATCH 0/8] NVPTX offloading to NVPTX: backend patches Jakub Jelinek
2016-10-14 16:40 Alexander Monakov
2016-10-14 16:40 ` [PATCH 3/8] nvptx -muniform-simt Alexander Monakov

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.LNX.2.20.1606131910560.28650@monopod.intra.ispras.ru \
    --to=amonakov@ispras.ru \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=nathan@acm.org \
    --cc=sandra@codesourcery.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).