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:

> 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?

Thanks,

	Ingo