Re: [PATCH 1/2] x86/segment: Introduce storesegment() helper to write segment selectors to memory

[Ingo Molnar <mingo@kernel.org>]

* Uros Bizjak <ubizjak@gmail.com> wrote:

> On Wed, Apr 1, 2026 at 8:40 AM Ingo Molnar <mingo@kernel.org> 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