From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109849 invoked by alias); 2 Dec 2016 16:59:49 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 109827 invoked by uid 89); 2 Dec 2016 16:59:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=optimizers, motion, Hx-languages-length:1533, statements X-Spam-User: qpsmtpd, 2 recipients X-HELO: relay1.mentorg.com Date: Fri, 02 Dec 2016 16:59:00 -0000 From: Joseph Myers To: Florian Weimer CC: Dave Martin , Yao Qi , , Ard Biesheuvel , Marc Zyngier , , Christoffer Dall , Alan Hayward , Torvald Riegel , Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support In-Reply-To: Message-ID: References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> <20161202114850.GQ1574@e103592.cambridge.arm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1152306461-1728650643-1480697967=:16956" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-12/txt/msg00063.txt.bz2 ---1152306461-1728650643-1480697967=:16956 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8BIT Content-length: 1481 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. 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. -- Joseph S. Myers joseph@codesourcery.com ---1152306461-1728650643-1480697967=:16956--