Re: [PATCH] add support for placing variables in shared memory

[Nathan Sidwell <nathan@acm.org>]

On 04/25/16 13:49, Alexander Monakov wrote:
> On Mon, 25 Apr 2016, Nathan Sidwell wrote:
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.).

Hm, -f{function/data}=sections would be the killer here.


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

If that's available, then great.

> 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:

I think we should  reject the cases where the backend gets to see an explicit 
initializer.


fno-common would be a good default for PTX (I had thought it was  already on?)

nathan