PR43381 notes that while we are good at matching `(X >> C1) & C2` as BEXTR/BEXTRI,
we only do that if we either have BEXTRI (TBM),
or if BEXTR is marked as being fast (`-mattr=+fast-bextr`).
In all other cases we don't match.
But that is mainly only true for AMD CPU's.
However, for all the CPU's for which we have sched models,
the BZHI is always fast (or the sched models are all bad.)
So if we decide that it's unprofitable to emit BEXTR/BEXTRI,
we should fall-back to BZHI if it is available,
and follow-up with the shift.
IndeedWhile it's really tempting to do something because it's cool
it is wise to first thing whether it actually makes sense to do.
We shouldn't just use BZHI because we can, but only it it is beneficial.
In particular, it isn't really worth it if the input is a register, BZHI does not have an immediate form,and mask is small.
bBut i think this is pretty identical to the BMI1 BEXTR situationt is worth it if the mask does not fit into 32-bits, or if we can fold the load.
(careful, i don't know much about intel cpu's my choice of `-mcpu` may be bad here)
Thus we manage to fold a load:
Or if we'd end up using BZHI anyways because the mask is large:
But this isn'r actually profitable in general case,
e.g. here we'd increase microop count
And if we don't(the register renaming is free, i think we still win some cycles:mca does not model that there it seems)