From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77158 invoked by alias); 2 Dec 2016 16:34:40 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 77086 invoked by uid 89); 2 Dec 2016 16:34:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=temporarily, statements X-Spam-User: qpsmtpd, 2 recipients 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 ESMTP; Fri, 02 Dec 2016 16:34:38 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3D47B8FCED; Fri, 2 Dec 2016 16:34:37 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-23.ams2.redhat.com [10.36.116.23]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2GYYdg013266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2016 11:34:35 -0500 Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support To: Dave Martin References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> <20161202114850.GQ1574@e103592.cambridge.arm.com> Cc: Yao Qi , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Alan Hayward , Torvald Riegel , linux-arm-kernel@lists.infradead.org From: Florian Weimer Message-ID: Date: Fri, 02 Dec 2016 16:34:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161202114850.GQ1574@e103592.cambridge.arm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00004.txt.bz2 On 12/02/2016 12:48 PM, Dave Martin wrote: > On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote: > > [...] > >> We could add a system call to get the right stack size. But as it depends >> on VL, I'm not sure what it looks like. Particularly if you need determine >> the stack size before creating a thread that uses a specific VL setting. > > I missed this point previously -- apologies for that. > > What would you think of: > > set_vl(vl_for_new_thread); > minsigstksz = get_minsigstksz(); > set_vl(my_vl); > > This avoids get_minsigstksz() requiring parameters -- which is mainly a > concern because the parameters tomorrow might be different from the > parameters today. > > If it is possible to create the new thread without any SVE-dependent code, > then we could > > set_vl(vl_for_new_thread); > new_thread_stack = malloc(get_minsigstksz()); > new_thread = create_thread(..., new_thread_stack); > set_vl(my_vl); > > which has the nice property that the new thread directly inherits the > configuration that was used for get_minsigstksz(). Because all SVE registers are caller-saved, it's acceptable to temporarily reduce the VL value, I think. So this should work. One complication is that both the kernel and the libc need to reserve stack space, so the kernel-returned value and the one which has to be used in reality will be different. > However, it would be necessary to prevent GCC from moving any code > across these statements -- in particular, SVE code that access VL- > dependent data spilled on the stack is liable to go wrong if reordered > with the above. So the sequence would need to go in an external > function (or a single asm...) I would talk to GCC folks—we have similar issues with changing the FPU rounding mode, I assume. Thanks, Florian