From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84110 invoked by alias); 2 Dec 2016 18:21:38 -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 84072 invoked by uid 89); 2 Dec 2016 18:21:36 -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_PASS autolearn=ham version=3.3.2 spammy=enjoy, statements X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 18:21:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 73EB0707; Fri, 2 Dec 2016 10:21:33 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BB5243F318; Fri, 2 Dec 2016 10:21:31 -0800 (PST) Date: Fri, 02 Dec 2016 18:21:00 -0000 From: Dave Martin To: Joseph Myers Cc: Florian Weimer , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Yao Qi , linux-arm-kernel@lists.infradead.org, Alan Hayward , Torvald Riegel , Christoffer Dall Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161202182126.GS1574@e103592.cambridge.arm.com> References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> <20161202114850.GQ1574@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-12/txt/msg00006.txt.bz2 On Fri, Dec 02, 2016 at 04:59:27PM +0000, Joseph Myers wrote: > On Fri, 2 Dec 2016, Florian Weimer wrote: > > > > 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. > > In general, GCC doesn't track the implicit uses of thread-local state > involved in floating-point exceptions and rounding modes, and so doesn't > avoid moving code across manipulations of such state; there are various > open bugs in this area (though many of the open bugs are for local rather > than global issues with code generation or local optimizations not > respecting exceptions and rounding modes, which are easier to fix). Hence > glibc using various macros such as math_opt_barrier and math_force_eval > which use asms to prevent such motion. Presumably the C language specs specify that fenv manipulations cannot be reordered with respect to evaluation or floating-point expressions? Sanity would seem to require this, though I've not dug into the specs myself yet. This doesn't get us off the hook for prctl() -- the C specs can only define constraints on reordering for things that appear in the C spec. prctl() is just an external function call in this context, and doesn't enjoy the same guarantees. > I'm not familiar enough with the optimizers to judge the right way to > address such issues with implicit use of thread-local state. And I > haven't thought much yet about how to implement TS 18661-1 constant > rounding modes, which would involve the compiler implicitly inserting > rounding modes changes, though I think it would be fairly straightforward > given underlying support for avoiding inappropriate code motion. My concern is that the compiler has no clue about what code motions are appropriate or not with respect to a system call, beyond what applies to a system call in general (i.e., asm volatile ( ::: "memory" ) for GCC). ? Cheers ---Dave