From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id F05653858C62 for ; Tue, 11 Jul 2023 14:57:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F05653858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 1E292223B0; Tue, 11 Jul 2023 14:57:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1689087423; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w5hJouKGK0Eonv1/8AAQK2QerEM2XWRiekX6P3jNltA=; b=go1Rf146G0tVcr2FS5+qvUpC3K+w/ReT99UZUyJ0qRPONxX971OQYo1cjbprWCp0vOKDP8 ZkIEqTOcBvkcTW91sOzQKt+bCtTH9NaL65nkxKDmG0GBrm6sXv1N5YEDgvvGRc9dBmKxHw w6n//CMFtmpXx+/9DgRS/QgpodhQ4/c= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1689087423; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=w5hJouKGK0Eonv1/8AAQK2QerEM2XWRiekX6P3jNltA=; b=aNqz8j81+08XmDNjtthUy9qsxHCTU+ewyxz9v2OUImuaE15jYVFbyYrhlBGkgNEAhB8vZ2 5s0/VwFXwEltFqBw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 10BA02C142; Tue, 11 Jul 2023 14:57:03 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id 04D2367F5; Tue, 11 Jul 2023 14:57:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id 039A16733; Tue, 11 Jul 2023 14:57:03 +0000 (UTC) Date: Tue, 11 Jul 2023 14:57:02 +0000 (UTC) From: Michael Matz To: Alexander Monakov cc: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [x86-64] RFC: Add nosse abi attribute In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-1173734276-1689087423=:13548" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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. ---1609957120-1173734276-1689087423=:13548 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello, On Mon, 10 Jul 2023, Alexander Monakov wrote: > 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": I want to provide both. One of them allows more arbitrary function definitions, the other allows more register (parts) to be preserved. I feel both have their place. > as Richi noted, surely for libcalls we'd like to know they preserve > AVX-512 mask registers as well? Yeah, mask registers. I'm still pondering this. We would need to split the 8 maskregs into two parts. Hmm. > 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. Yeah, needs to be kept in mind indeed. Anything coming in between the caller and a so-marked callee needs to preserve things. > > 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)? I hoped early on that the generic code that prohibits sibcalls between call sites of too "different" ABIs would deal with this, and then forgot to check. Turns out you had a good hunch here, it actually does a sibcall, destroying the guarantees. Thanks! :) > > 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? Hmm. I feel the best answer here is "that should error out". I'll add a test and adjust patch if necessary. > > 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)); ? Makes a good testcase as well. My take: it's acceptable with the only-sse2-preserved attribute (xmm15 will in this case be saved/restored), and should be an error with the everything-preserved attribute (maybe we can make an exception as here we only specify an XMM reg, instead of larger parts). > > 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". But it preserves only the low parts :-) You swapped the two in your mind when writing the reply? > > 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. Yes, like all ABI influencing attributes they _have_ to be part of the functions type (and hence transfer to function pointers), with appropriate incompatible-conversion errors and warnings at the appropriate places. (I know that this isn't always the way we're dealing with ABI-infuencing attributes, and often refer to a decl only. All those are actual bugs.) And yes, I will adjust the docu to be explicit about this. Ciao, Michael. ---1609957120-1173734276-1689087423=:13548--