On 31/07/18 14:57, Segher Boessenkool wrote: > Hi Christophe, > > On Tue, Jul 31, 2018 at 02:34:06PM +0200, Christophe Lyon wrote: >> Since this was committed, I've noticed regressions >> on aarch64: >> FAIL: gcc.dg/zero_bits_compound-1.c scan-assembler-not \\(and: > > This went from > and w0, w0, 255 > lsl w1, w0, 8
These are sequentially dependent. > orr w0, w1, w0, lsl 20 > ret > to > and w1, w0, 255 > ubfiz w0, w0, 8, 8 These can run in parallel. So the change is a good one! On a super-scalar machine we save a cycle. R. > orr w0, w0, w1, lsl 20 > ret > so it's neither an improvement nor a regression, just different code. > The testcase wants no ANDs in the RTL. > > >> on arm-none-linux-gnueabi >> FAIL: gfortran.dg/actual_array_constructor_1.f90 -O1 execution test > > That sounds bad. Open a PR, maybe? > > >> On aarch64, I've also noticed a few others regressions but I'm not yet >> 100% sure it's caused by this patch (bisect running): >> gcc.target/aarch64/ashltidisi.c scan-assembler-times asr 4 > > ushift_53_i: > - uxtw x1, w0 > - lsl x0, x1, 53 > - lsr x1, x1, 11 > + lsr w1, w0, 11 > + lsl x0, x0, 53 > ret > > shift_53_i: > - sxtw x1, w0 > - lsl x0, x1, 53 > - asr x1, x1, 11 > + sbfx x1, x0, 11, 21 > + lsl x0, x0, 53 > ret > > Both are improvements afais. The number of asr insns changes, sure. > > >> gcc.target/aarch64/sve/var_stride_2.c -march=armv8.2-a+sve >> scan-assembler-times \\tadd\\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 10\\n 2 > > Skipping all the SVE tests, sorry. Richard says they look like > improvements, and exactly of the expected kind. :-) > > > Segher >
