On 2/6/26 09:22, Paolo Bonzini wrote:
Il gio 5 feb 2026, 23:29 Richard Henderson <[email protected]
<mailto:[email protected]>> ha scritto:
> > I think it would be better to pick a canonical form for AND with
2^n-1 and
handle
> > conversion to extract (like PPC rotates or movz) in the backend.
> >
> > Picking AND as the canonical form also avoids makes the macros
for extract
validity
> > simpler too; adding an extra constraint for immediate 2^n-1 is
easier and it
> generalizes
> > to other PPC rotate and mask cases.
>
> Picking AND means we have to use "r,0,ri" for x86, losing register
allocation
flexibility.
>
>
> Then could you wrap the target specific extract_valid with one that
allows ofs == 0
if AND
> allows the immediate 2^len-1? That would also simplify this series.
I don't understand your suggestion here.
I am not sure about it either... I am just not sure why extract is guaranteed to be
cheaper or have better constraints than AND.
It does happen to be true for x86, though only for len == 8 or 16; but is it true of all
targets that have a more expansive extract instruction?
x86 includes len == 32 via 'movl', fwiw.
Similarly, riscv64 has quite a number of filter conditions for extract, mostly because of
a 12-bit signed argument for AND, and a collection of other zero-extend insns.
AArch64, loongarch64, and ppc64 all emit ANDI if possible during tgen_extract.
So it really is all about using extract if valid, and allowing the backend to use the more
favorable set of constraints.
r~
