public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexander Monakov <amonakov@ispras.ru>
To: Nathan Sidwell <nathan@acm.org>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] add support for placing variables in shared memory
Date: Mon, 25 Apr 2016 17:49:00 -0000	[thread overview]
Message-ID: <alpine.LNX.2.20.1604251954290.5702@monopod.intra.ispras.ru> (raw)
In-Reply-To: <571E2E0F.7040204@acm.org>

On Mon, 25 Apr 2016, Nathan Sidwell wrote:
> On 04/22/16 10:04, Alexander Monakov wrote:
> > echo 'int v __attribute__((section("foo")));' |
> >    x86_64-pc-linux-gnu-accel-nvptx-none-gcc -xc - -o /dev/null
> > <stdin>:1:5: error: section attributes are not supported for this target
> 
> Presumably it's missing a necessary hook?  Couldn't such a hook check the
> section name is acceptable?

No, that really doesn't sound viable.  You'd need to somehow take into account
every instance where the compiler attempts to switch sections internally
(.text/.data/.bss, -ffunction-sections/-fdata-sections etc.).

> > > Why can it not apply to  variables of auto storage?  I.e. function scope,
> > > function lifetime?  That would seem to be a useful property.
> >
> > Because PTX does not support auto storage semantics for .shared data.  It's
> > statically allocated at link time.
> 
> I  suppose it's not worth going through hoops to define such function-scoped
> variables if PTX isn't going to take advantage of that.

It's not even about 'taking advantage', basic correctness expectations would be
violated (with auto storage you get new instances of the variable when
reentering function scope recursively).

> > > What happens if an initializer is present, is it silently ignored?
> >
> > GCC accepts and reemits it in assembly output (if non-zero), and ptxas
> > rejects
> > it ("syntax error").
> 
> ptx errors are inscrutable.
> 
> It would be better for nvptx_assemble_decl_end to check if an initializer has
> been output and emit an error (you'll need to record the decl itself in the
> initializer structure to do that).  Record the  decl in
> nvptx_assemble_decl_begin if the symbol's data area is .shared, and then check
> in NADE?

Ugh.  Checking DECL_INITIAL in nvptx_encode_section_info would be much
simpler (and that's how other backends perform a similar test).

Note, rejecting zero-initializers is debatable:
C and C++ don't have a concept of uninitialized global-scope data; if
the initializer is missing, it's exactly as if it was 0.  However, GCC has
-fcommon enabled by default (which, btw, shouldn't we change on NVPTX?), and
that makes a difference: 'int v = 0;' is a strong definition, while 'int v;'
becomes a common symbol, and ultimately a weak definition on NVPTX.

So if all-zeros initializers are rejected, to make a strong definition of a
shared variable one would have to write:

  int v __attribute__((shared,nocommon));

With -fno-common enabled by default on this target that wouldn't be an issue.

Thanks.
Alexander

  reply	other threads:[~2016-04-25 17:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-20 16:58 Alexander Monakov
2016-04-21 14:00 ` Nathan Sidwell
2016-04-21 14:25   ` Alexander Monakov
2016-04-22 13:09     ` Nathan Sidwell
2016-04-22 14:04       ` Alexander Monakov
2016-04-25 14:47         ` Nathan Sidwell
2016-04-25 17:49           ` Alexander Monakov [this message]
2016-04-26 13:06             ` Nathan Sidwell
2016-05-06 17:11 ` [PATCH v2] " Alexander Monakov
2016-05-09 13:39   ` Nathan Sidwell

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