From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90973 invoked by alias); 26 Apr 2016 13:06:53 -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 90961 invoked by uid 89); 26 Apr 2016 13:06:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1345 X-HELO: mail-qk0-f169.google.com Received: from mail-qk0-f169.google.com (HELO mail-qk0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Apr 2016 13:06:50 +0000 Received: by mail-qk0-f169.google.com with SMTP id n63so4999789qkf.0 for ; Tue, 26 Apr 2016 06:06:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=bU5kHswPXcMleIOst1p1HAu8y+P2vQk7eLNUo4nzZls=; b=OGfK4OsbWlIqRKbpCHGIpAM/mUhBWSCy8jI0Dog48oWi/cTHp9H7O8GmUpKUQYdxAs MMn/fBN8HmloCMmkkT4psBULYH2dWqL6PvcmbxLpRvK13NFvCzzoNyPoirMNrovn8VHl lECnrsQxqYq8sq3J9YwiI0ip5HvOh7mQswAO00c+cR2mM/aT6GX6un+XZsh4zUZUOnnw yT8sT+BEctMXoU5AAztXuIpJilvcUXP91D2248EAWmo7MG+FmJub+x8c4vJ2a6tVK4jR 5LQ4N8EBictcRieUGx9pbtAl4zIxS8EyAztwPv+2EnPvTO5iXyhJG8whp29avZsNLymc iWWQ== X-Gm-Message-State: AOPr4FXGaCTw6On3pJ+pMtBd+oqpTlfbYtnZpMu5t4AnMnDQjoaaof7jF9xJegiQxajvJQ== X-Received: by 10.55.18.12 with SMTP id c12mr2217225qkh.158.1461676008283; Tue, 26 Apr 2016 06:06:48 -0700 (PDT) Received: from ?IPv6:2601:181:c003:1930:a2a8:cdff:fe3e:b48? ([2601:181:c003:1930:a2a8:cdff:fe3e:b48]) by smtp.googlemail.com with ESMTPSA id o24sm8799279qko.32.2016.04.26.06.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2016 06:06:47 -0700 (PDT) Subject: Re: [PATCH] add support for placing variables in shared memory To: Alexander Monakov References: <5718DCF0.5000808@acm.org> <571A226B.9020906@acm.org> <571E2E0F.7040204@acm.org> Cc: gcc-patches@gcc.gnu.org From: Nathan Sidwell Message-ID: <571F67E6.6010803@acm.org> Date: Tue, 26 Apr 2016 13:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg01481.txt.bz2 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