https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87433
--- Comment #3 from Steve Ellcey <sje at gcc dot gnu.org> --- Based on that email string, gcc.target/aarch64/ashltidisi.c can be fixed by looking for 3 asr instructions instead of 4. That seems simple enough. The new code has two fewer instructions that the old code: < NEW CODE > OLD CODE 11,12c11,13 < lsr w1, w0, 11 < lsl x0, x0, 53 --- > uxtw x1, w0 > lsl x0, x1, 53 > lsr x1, x1, 11 24,25c25,27 < sbfx x1, x0, 11, 21 < lsl x0, x0, 53 --- > sxtw x1, w0 > lsl x0, x1, 53 > asr x1, x1, 11 But gcc.dg/zero_bits_compound-1.c is not an aarch64 specific test, we are seeing 'and' expressions in the rtl on aarch64. Based on the email string that seems OK. It generates the same number of instructions as before but there is a some opportunity for doing some of them in parallel. But the test doesn't seem to be failing on the x86 or s390 platforms so should we just not run it on aarch64 anymore? That would seem like the right fix to me, I don't think the test makes sense on aarch64 anymore.
