From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F929236453 for ; Wed, 1 Apr 2026 06:40:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775025650; cv=none; b=V5yjL2Eq0pQHDnMo3/Y+6sGbXxNmwuKzB6qXZXtNZ/IgSjD/pZlHJISgPvUb/bwME/KhgTWw18EHXmHrRe7/MwUbFuHLK0dk05Wa6i/l98UntD0/fiz0Zke//HoNtR/MbASIMc+LwVDH5E6gItiUkOs8yCqEV47vZ6deYLHXZBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775025650; c=relaxed/simple; bh=2ZTiuWI6s0bsd83R/WWlmOdOtd/W9GV6Mtau4I5spSs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=syMYZvez0QyRkgXiDC7FySrrznbkhw5VDQVyaCUzbEJAP/W5Xgx0ReWjKBa6KbncffVgtazrK5AXES2cwEKuchYmgk+uAyL/rIy+BA0k42/aYyVXQyASXkPUw/jCkIQW2LjdtSHORhsNrwJ95p5peyAsxz1u8xCoZetWAj6yoC4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZvTX/XnX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZvTX/XnX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E1FCC4CEF7; Wed, 1 Apr 2026 06:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775025650; bh=2ZTiuWI6s0bsd83R/WWlmOdOtd/W9GV6Mtau4I5spSs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ZvTX/XnX1BbG94GwWmtHDMoC1lJQ932LsfDiU3QZy6/SPjbvn5GY+BbleHJth1Sbk qdxe2sgWZmD4VpdYACojKTVSl3N0+4WFY8EmdKUPYpXHAhtgMNTI7LbPQkmWWcquUI ZjE/T+2GBR+juBNzgiphrDWesQcjg/gilBFb9vuDfUDShDL5lbC9Jsrn7iWP4cO501 ovQlQNALpLoka+LbTFpAQhQBh1KuD/J5lrJcRadoCGv9ObyidUojr7a6+/IRgQLQO5 YRhK5R4D970c1Aj3kPOsIYzUTKqM0TdD/9DvEHb/w9+XCA0WIgI87uvSBgtLdKzk8R kSHdA4yBqdZdw== Date: Wed, 1 Apr 2026 08:40:45 +0200 From: Ingo Molnar To: Uros Bizjak Cc: x86@kernel.org, linux-kernel@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Borislav Petkov , Dave Hansen Subject: Re: [PATCH 1/2] x86/segment: Introduce storesegment() helper to write segment selectors to memory Message-ID: References: <20260331063838.108857-1-ubizjak@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: * Uros Bizjak wrote: > On Tue, Mar 31, 2026 at 8:56 AM Ingo Molnar wrote: > > > > > > * Uros Bizjak wrote: > > > > > Introduce a new helper, storesegment(), that stores a segment selector > > > directly into a u16 (or compatible) memory location without using an > > > intermediate general-purpose register. > > > > > > To support this, split the existing SAVE_SEGMENT macro into two parts: > > > > > > SAVE_SEGMENT_VAR(): retains the current behavior of reading a segment > > > register into an unsigned long via a register. > > > SAVE_SEGMENT_PTR(): adds a new variant that writes the 16-bit selector > > > directly to memory. > > > > > > The combined SAVE_SEGMENT() macro now generates both helpers for each > > > segment register. > > > > > > The new storesegment() interface is preferred over savesegment() when > > > the value only needs to be stored (e.g. into a struct field), avoiding > > > an unnecessary register move and making the intent clearer. > > > > > > No functional change for existing users of savesegment(). > > > > Why does the API have to be split into =r and =m variants? > > > > Coulnd't we use a more generic constraint and let the compiler > > decide what the target is? Would that negatively impact > > other aspects of code generation? > > The "=r" variant actually outputs zero-extended value to the whole > register width. So, the "=r" variant is used to eliminate > zero-extensions when the value is used in the follow-up calculations, > comparisons, or when the value is stored to a location that is more > than 16-bits wide. Additionally, "r" variant always uses MOVL, where > operand size prefix byte (0x66) is not needed. > > The "=m" variant only outputs to a 16-bit location. Having "=rm" here > would always emit a 0x66 operand size prefix when register is used as > an output, and there would be many zero-extensions emitted, because > the compiler needs to zero-extend the value from 'unsigned short' to > anything wider. > > Other than that, GCC (and Clang, too) has serious problems with "=rm" > output constraints. Forward propagation (AKA combine pass) does not > work reliably with assembly outputs (due to always present clobbers > for assembly clauses), so there will be many cases of moves to a > temporary register and even to a temporary stack location with this > constraint. Having two separate functions (with clear and > informational function comment) leaves the decision to the programmer, > which function is the most optimal. Yeah, so I still have a problem with the split API, 'savesegment()' is very similar to 'storesegment()' and there's no real way to tell them apart in practice. Since the main difference is that the =m variant outputs to an u16, I'd suggest naming the two APIs according to the type they handle, not some random word that nobody remembers: savesegment() savesegment_u16() ... or so? Thanks, Ingo