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
Hi Modi,
> 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 tbnz etc. matches GPI and that brings code size down to <0.2% in
> spec2017 and <0.4% in
Hi Modi,
> 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 tbnz etc. matches GPI and that brings code size down to <0.2% in
> spec2017 and <0.4% in
> > 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
Hi,
Richard wrote:
> However, inside the compiler we really want to represent this as a
>shift.
...
> Ideally this would be handled inside the mid-end expansion of an
> extract, but in the absence of that I think this is best done inside the
> extv expansion so that we never end up with a real
On 07/02/2020 02:12, Modi Mo via gcc-patches wrote:
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])
> 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 Modi,
Thanks for your patch!
> 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 t
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
