[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-12-11 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

Richard Earnshaw  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Earnshaw  ---
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.

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-12-11 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

--- Comment #2 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Dec 11 11:26:15 2018
New Revision: 267019

URL: https://gcc.gnu.org/viewcvs?rev=267019=gcc=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.
(copysign3): New expand pattern.
(copysign3_insn): New insn pattern.


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

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-12-10 Thread rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|samtebbs at gcc dot gnu.org|rearnsha at gcc dot 
gnu.org

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-12-06 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

--- Comment #1 from Jeffrey A. Law  ---
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.

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-12-06 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-06
 CC||law at redhat dot com
 Ever confirmed|0   |1

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

2018-09-24 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87369

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|Regression on   |[9 Regression] Regression
   |aarch64/copysign-bsl.c  |on aarch64/copysign-bsl.c
   |since r264264   |since r264264