https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #27 from wilco at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #26) > (In reply to wilco from comment #25) > > > > Alternatives can be disabled, there are flags, eg: > > > > (set_attr "arch" "neon_for_64bits,*,*,avoid_neon_for_64bits") > > > > Ok I see, thanks. > > Still lots of insns could be simplified into less alternatives, > when the attribs are identical of course. Doesn't that create > smaller tables and use less memory to compile? Quite likely yes, but more importantly it will generate better code by not accidentally allocating to FP registers. There are many integer variants that have a '?' which seems incorrect. > > I think the NEON alternatives not only do not help at all, they actually > > generate cause CQ to be far worse even when no NEON instructions are ever > > generated. > > Yes. At least when not fpu is available, there can't possibly be > any benefit from these insns. Sure there will be cases when > the fpu instructions can improve something, just not here. It's hard to imagine cases where using NEON for 64-bit operations is beneficial - the extra moves to and from NEON registers are expensive on many cores, and NEON operations have higher latencies than equivalent integer instructions. Note I tried setting SLOW_UNALIGNED_ACCESS to false in addition to your patch. This emits the rev instruction as expected, and size goes down to ~4400 instructions with -mthumb -march=armv7 -mfloat-abi=soft -Os. With -O2 -mthumb -mfpu=vfp the reduction is even more dramatic from around 7300 instructions to just 5000...
