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 C8FBF2FD7BC for ; Wed, 1 Apr 2026 07:02:38 +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=1775026958; cv=none; b=TYSdtt8VHPrhu1vZ+hnPdyhxazPAkH/fhbBG5gBj7LxHh4uOQGe5PTqIlN8EEWDz77RC6Hbe3mP/y/VxWSvLcr7kgWJCxy/i03DVqID0m55gHXlReVdcNlrwLhbbSZtVTNqQU+yxXrlnPu2fqeiJB7LL9MrH2naeGVRo7T1q3Jw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775026958; c=relaxed/simple; bh=ViwjqFBbKVM7zjHDC4aF757vLDJXAi2PGZ3mFy606z4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uyoN9672t3Gudhjw2LCzeNvop460dwvwwR8iYGJCmRfvk6flwD1qjBr+4Gv8z7ycsQieYdmWqaDjIs/wfxxQITQnLsCH8KmSHUz5gwhnLToCa/OQxMIVLeHxoxTdzevSyaxRZlJ0cZMit8FnVKPTwodgsLe8nrJiBPxn8Hijpq0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DFRIruMn; 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="DFRIruMn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9663DC4CEF7; Wed, 1 Apr 2026 07:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775026958; bh=ViwjqFBbKVM7zjHDC4aF757vLDJXAi2PGZ3mFy606z4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=DFRIruMnmMYj6/YKAi4dHi5Nns9xmzADWgGjj1uOwl+VpNs0ZLG2zEDREuWZ+CKKa WE5VB7blXpDxF/aHjF+uGSHIMLRFTJqo8hMsILvuQsdFxiG5wVOKmSZt9JmsjKX0zY C1ctd80StSv/nQO1pz954Tn7Xusczo8tKA1PIKkPb93AS08hXLdaOw2JH2cB4Rx1YF bdrTS+302Sh3UNsPj1+/3pYQzes5ltA40DubDFWKsnGBmuNTNnshIXs5ANUDOffM0F rNhaQd2MPtJ/JQAqBNFc8gwGy6gHfoNAE8QYDw/kBGwDfec0OtxhAIQadaEHjq8G15 5wy7GTyqTHK1A== Date: Wed, 1 Apr 2026 09:02:33 +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 Wed, Apr 1, 2026 at 8:40 AM Ingo Molnar wrote: > > > > > 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? > > Yes, the above is a good proposal. I was undecided how to name the new > function, but the above is definitely more informative. Maybe also > emphasize that the new function operates on memory, so: > > savesegment_mem16() > > (the location does not need to be unsigned)? Sounds good to me. Thanks, Ingo