From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53405 invoked by alias); 22 Apr 2016 13:09:07 -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 53384 invoked by uid 89); 22 Apr 2016 13:09:06 -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= X-HELO: mail-qk0-f170.google.com Received: from mail-qk0-f170.google.com (HELO mail-qk0-f170.google.com) (209.85.220.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 22 Apr 2016 13:09:03 +0000 Received: by mail-qk0-f170.google.com with SMTP id q76so25914847qke.2 for ; Fri, 22 Apr 2016 06:09:03 -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=gvH9T3a/2M4rmH9FQe7aRkic1xALVvICSAHmTi+pyDQ=; b=DRX/tbXXRM7ncX9i0qsBHsEqaXxVqUB43fpXPTjXBBFVKpPGaBM3CAdFWkBG3up8C2 bc6/1PSbb1DRy5n3x41833CsCubAKIEJ0LqlcUCksbCjjTjMdfJQRZH9hPmfSc+zgr48 iF6bLnUVx4iMnf7unzDhObuF5OmLBA0h94w/6dAbVxkzb/1OaThaaL3rI40hM+d6NXI0 6eAL2N7aNfJI3uWfjSAE9Jt8C45nEqVmoUSeuHEurZVlD3FEODMVaLmqV8E5ey06K0HT AUf0VtPxMIijUJe7aRCZ44HlDiMALS25dGXL6hjX879Xpt2nzXP9a+bTjPjvwErJQfZc wKfQ== X-Gm-Message-State: AOPr4FX1upSDIJB+7WEJDi1zPqEtfFMqr0fW3rRb7uLSl3d8k+mEsDuCDa/RTvQ5a3luMw== X-Received: by 10.55.88.5 with SMTP id m5mr4443245qkb.134.1461330541438; Fri, 22 Apr 2016 06:09:01 -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 c2sm2331968qkb.41.2016.04.22.06.09.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Apr 2016 06:09:00 -0700 (PDT) Subject: Re: [PATCH] add support for placing variables in shared memory To: Alexander Monakov References: <5718DCF0.5000808@acm.org> Cc: gcc-patches@gcc.gnu.org From: Nathan Sidwell Message-ID: <571A226B.9020906@acm.org> Date: Fri, 22 Apr 2016 13:09: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/msg01254.txt.bz2 On 04/21/16 10:25, Alexander Monakov wrote: > On Thu, 21 Apr 2016, Nathan Sidwell wrote: >> On 04/20/16 12:58, Alexander Monakov wrote: >>> Allow using __attribute__((shared)) to place static variables in '.shared' >>> memory space. >> >> What is the rationale for a new attribute, rather than leveraging the existing >> section(".shared") machinery? > > Section switching does not work at all on NVPTX in GCC at present. PTX > assembly has no notion of different data sections, so the backend does not > advertise section switching capability to the middle end. Correct. How is that relevant? Look at DECL_SECTION_NAME in encode_section_info. > CUDA C does it via attributes too, and there's no point in diverging > gratuitously I think. Also correct. It seems you're trying to make the compiler look like CUDA rather than fit new features into existing idioms. > I avoided using 'static' because it applies to external declarations as well. > Other backends use "%qE attribute not allowed with auto storage class"; I'll > be happy to switch to that for consistency. Why can it not be applied to external declarations? Doesn't '.extern .shared whatever' work? Why can it not apply to variables of auto storage? I.e. function scope, function lifetime? That would seem to be a useful property. What happens if an initializer is present, is it silently ignored? thinking further the uninitialized behaviour might be a reason for not going with section(".shared"). nathan