From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id DB8693858CDA for ; Mon, 10 Jul 2023 19:07:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB8693858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id B073F40AE018; Mon, 10 Jul 2023 19:07:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru B073F40AE018 Date: Mon, 10 Jul 2023 22:07:35 +0300 (MSK) From: Alexander Monakov To: Michael Matz cc: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [x86-64] RFC: Add nosse abi attribute In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8323328-1284333339-1689016055=:8926" X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1284333339-1689016055=:8926 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT On Mon, 10 Jul 2023, Michael Matz via Gcc-patches wrote: > Hello, > > the ELF psABI for x86-64 doesn't have any callee-saved SSE > registers (there were actual reasons for that, but those don't > matter anymore). This starts to hurt some uses, as it means that > as soon as you have a call (say to memmove/memcpy, even if > implicit as libcall) in a loop that manipulates floating point > or vector data you get saves/restores around those calls. > > But in reality many functions can be written such that they only need > to clobber a subset of the 16 XMM registers (or do the save/restore > themself in the codepaths that needs them, hello memcpy again). > So we want to introduce a way to specify this, via an ABI attribute > that basically says "doesn't clobber the high XMM regs". I think the main question is why you're going with this (weak) form instead of the (strong) form "may only clobber the low XMM regs": as Richi noted, surely for libcalls we'd like to know they preserve AVX-512 mask registers as well? (I realize this is partially answered later) Note this interacts with anything that interposes between the caller and the callee, like the Glibc lazy binding stub (which used to zero out high halves of 512-bit arguments in ZMM registers). Not an immediate problem for the patch, just something to mind perhaps. > I've opted to do only the obvious: do something special only for > xmm8 to xmm15, without a way to specify the clobber set in more detail. > I think such half/half split is reasonable, and as I don't want to > change the argument passing anyway (whose regs are always clobbered) > there isn't that much wiggle room anyway. > > I chose to make it possible to write function definitions with that > attribute with GCC adding the necessary callee save/restore code in > the xlogue itself. But you can't trivially restore if the callee is sibcalling — what happens then (a testcase might be nice)? > Carefully note that this is only possible for > the SSE2 registers, as other parts of them would need instructions > that are only optional. What is supposed to happen on 32-bit x86 with -msse -mno-sse2? > When a function doesn't contain calls to > unknown functions we can be a bit more lenient: we can make it so that > GCC simply doesn't touch xmm8-15 at all, then no save/restore is > necessary. What if the source code has a local register variable bound to xmm15, i.e. register double x asm("xmm15"); asm("..." : "+x"(x)); ? Probably "dont'd do that", i.e. disallow that in the documentation? > If a function contains calls then GCC can't know which > parts of the XMM regset is clobbered by that, it may be parts > which don't even exist yet (say until avx2048 comes out), so we must > restrict ourself to only save/restore the SSE2 parts and then of course > can only claim to not clobber those parts. Hm, I guess this is kinda the reason a "weak" form is needed. But this highlights the difference between the two: the "weak" form will actively preserve some state (so it cannot preserve future extensions), while the "strong" form may just passively not touch any state, preserving any state it doesn't know about. > To that end I introduce actually two related attributes (for naming > see below): > * nosseclobber: claims (and ensures) that xmm8-15 aren't clobbered This is the weak/active form; I'd suggest "preserve_high_sse". > * noanysseclobber: claims (and ensures) that nothing of any of the > registers overlapping xmm8-15 is clobbered (not even future, as of > yet unknown, parts) This is the strong/passive form; I'd suggest "only_low_sse". > Ensuring the first is simple: potentially add saves/restore in xlogue > (e.g. when xmm8 is either used explicitely or implicitely by a call). > Ensuring the second comes with more: we must also ensure that no > functions are called that don't guarantee the same thing (in addition > to just removing all xmm8-15 parts alltogether from the available > regsters). > > See also the added testcases for what I intended to support. > > I chose to use the new target independend function-abi facility for > this. I need some adjustments in generic code: > * the "default_abi" is actually more like a "current" abi: it happily > changes its contents according to conditional_register_usage, > and other code assumes that such changes do propagate. > But if that conditonal_reg_usage is actually done because the current > function is of a different ABI, then we must not change default_abi. > * in insn_callee_abi we do look at a potential fndecl for a call > insn (only set when -fipa-ra), but doesn't work for calls through > pointers and (as said) is optional. So, also always look at the > called functions type (it's always recorded in the MEM_EXPR for > non-libcalls), before asking the target. > (The function-abi accessors working on trees were already doing that, > its just the RTL accessor that missed this) > > Accordingly I also implement some more target hooks for function-abi. > With that it's possible to also move the other ABI-influencing code > of i386 to function-abi (ms_abi and friends). I have not done so for > this patch. > > Regarding the names of the attributes: gah! I've left them at > my mediocre attempts of names in order to hopefully get input on better > names :-) > > I would welcome any comments, about the names, the approach, the attempt > at documenting the intricacies of these attributes and anything. I hope the new attributes are supposed to be usable with function pointers? >From the code it looks that way, but the documentation doesn't promise that. > FWIW, this particular patch was regstrapped on x86-64-linux > with trunk from a week ago (and sniff-tested on current trunk). This looks really cool. Thanks. Alexander --8323328-1284333339-1689016055=:8926--