I wonder if we would be better off having the bfxil pattern reject cases when just the high bit is on (which are those cases where we'd be able to use a bit instruction rather than bfxil.

Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019

URL: https://gcc.gnu.org/viewcvs?rev=267019&root=gcc&view=rev
Log:
[aarch64] PR target/87369 Prefer bsl/bit/bif for copysign

The copysign operations will almost always be performed on values in
floating-point registers.  As such, we do not want the compiler to
simplify the operations into code sequences that can only be done
using the general-purpose register set.  Unfortunately, this is what
is currently happening.

Fortunately, it seems quite unlikely that copysign() will be
subsequently followed by other logical operations on the values
involved, so I think it is acceptable to use an unspec here.  This
allows us to preserve the operation in a form that allows the register
allocator to make the right choice later on, without limitation on the
final form of the operation (well, if we do end up using the gp
register bank, we get a dead constant load that we cannot easily
eliminate at a late stage).

	PR target/37369
	* config/aarch64/iterators.md (sizem1): Add sizes for SFmode and DFmode.
	(Vbtype): Add SFmode mapping.
	* config/aarch64/aarch64.md (copysigndf3, copysignsf3): Delete.
	(copysign<GPF:mode>3): New expand pattern.
	(copysign<GPF:mode>3_insn): New insn pattern.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/aarch64/aarch64.md
    trunk/gcc/config/aarch64/iterators.md

It seems better to fix this by using an unspec that's specific to the copysign expansion.  That means we don't need to nobble the other optimizations the compiler might do on bit-field manipulations.  It's unlikely that copysign will be followed by other bit-manipulating operations on a FP value, but we'll just have to live with that if they are.