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

[Uros Bizjak]

On Wed, Apr 1, 2026 at 8:40 AM Ingo Molnar <mingo@xxxxxxxxxx> 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)?

Thanks,
Uros.