Hey all-apologies for the long delay. Haven't had time until recently to look
into this further.
>>> The zero extract now matching against other modes would generate a
>>> test + branch rather than the combined instruction which led to the
>>> code size regression. I've updated the patch so that t
> > Sounds good. I'll get those setup and running and will report back on
> > findings. What's the preferred way to measure codesize? I'm assuming
> > by default the code pages are aligned so smaller differences would need to
> > trip
> over the boundary to actually show up.
>
> You can use the s
> I did a quick bootstrap, this shows several failures like:
>
> gcc/builtins.c:9427:1: error: unrecognizable insn:
> 9427 | }
> | ^
> (insn 212 211 213 24 (set (reg:SI 207)
> (zero_extract:SI (reg:SI 206)
> (const_int 26 [0x1a])
> (const_int 6 [0x6]))) "/gcc
Hi,
Adding support for extv and extzv on aarch64 as described in
PR86901. I also changed extract_bit_field_using_extv to use
gen_lowpart_if_possible instead of gen_lowpart directly. Using gen_lowpart
directly will fail with an ICE in building libgcc when the compiler fails to
successfully do s
