From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70268 invoked by alias); 25 Apr 2016 17:49:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 70252 invoked by uid 89); 25 Apr 2016 17:49:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*M:intra, ugh, HTo:U*nathan X-HELO: smtp.ispras.ru Received: from smtp.ispras.ru (HELO smtp.ispras.ru) (83.149.199.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Apr 2016 17:49:10 +0000 Received: from [10.10.3.121] (unknown [83.149.199.91]) by smtp.ispras.ru (Postfix) with ESMTP id 8FD3E2040E; Mon, 25 Apr 2016 20:49:07 +0300 (MSK) Date: Mon, 25 Apr 2016 17:49:00 -0000 From: Alexander Monakov To: Nathan Sidwell cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] add support for placing variables in shared memory In-Reply-To: <571E2E0F.7040204@acm.org> Message-ID: References: <5718DCF0.5000808@acm.org> <571A226B.9020906@acm.org> <571E2E0F.7040204@acm.org> User-Agent: Alpine 2.20 (LNX 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-04/txt/msg01405.txt.bz2 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 > > :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