From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 81802 invoked by alias); 30 Nov 2015 11:23:47 -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 81787 invoked by uid 89); 30 Nov 2015 11:23:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 30 Nov 2015 11:23:46 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id DA8A68E6EF; Mon, 30 Nov 2015 11:23:44 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-34.ams2.redhat.com [10.36.116.34]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUBNh2n007660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Nov 2015 06:23:44 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id tAUBNfwX022410; Mon, 30 Nov 2015 12:23:42 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id tAUBNedp022409; Mon, 30 Nov 2015 12:23:40 +0100 Date: Mon, 30 Nov 2015 11:25:00 -0000 From: Jakub Jelinek To: Alexander Monakov Cc: gcc-patches@gcc.gnu.org, Bernd Schmidt , Dmitry Melnik Subject: Re: [PATCH] nvptx: implement automatic storage in custom stacks Message-ID: <20151130112340.GA5675@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20151130103237.GY5675@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg03462.txt.bz2 On Mon, Nov 30, 2015 at 02:14:41PM +0300, Alexander Monakov wrote: > On Mon, 30 Nov 2015, Jakub Jelinek wrote: > > Does your patch affect all the stack allocations within certain function > > (i.e. no way to select on a per-variable bases what stack to allocate it > > to)? Without any detailed analysis at least e.g. spilled (non-addressable) > > vars could at least go to the local stack. But PTX doesn't have any spills, > > right? Not sure about HSA. If it is a per-function thing only, then it > > isn't worth to do more detailed analysis at the ompexp time. > > Yes, there's no register allocation and thus no spills on PTX. > > > BTW, surely it will be an advantage if PTX can support alloca through this, > > it could e.g. turn on -msoft-stack for all functions that use alloca/VLAs > > automatically. > > Yes, I'm going to support alloca on soft stacks, but, -msoft-stack has a > prerequisite of soft stacks being initially set up. Therefore I'm treating it > as an ABI variant (together with another option to handle atomics and > "syscalls" outside of simd regions), and building a separate multilib for > that. So I see it the other way around: it's not safe for the compiler to > always use soft-stacks for alloca (because OpenACC wouldn't set up soft > stacks), but if soft stacks are enabled, alloca can use them. > > In the multilib variant that I'm introducing, all addressable vars go to soft > stacks, and classic .local stacks are used rarely, e.g. for stdarg passing, > and implicitely for calls/returns (and after JIT, they'll service register > spills too). Does it really have to be a full multilib? I mean, the only precondition is that something sets up the var, right? Would the OpenACC folks be willing to set it up too? For stuff like libc, functions that are ECF_LEAF builtins IMHO really don't care whether they are built as -msoft-stack or not, they shouldn't be passing addresses of local vars to code that could use OpenMP. The only question is if say qsort or other functions that call user callbacks could be passing addresses of local vars to those callbacks, or whether they only pass addresses passed from callers, or addresses of heap objects. Jakub