[Bug target/64897] Floating-point "and" not optimized on x86-64

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64897

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
             Target|                            |x86_64-*-*, i?86-*-*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-02
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
We expand from

fand1 (double x)
{
  long unsigned int _2;
  long unsigned int ix.1_4;

  <bb 2>:
  _2 = VIEW_CONVERT_EXPR<long unsigned int>(x_5(D));
  ix.1_4 = _2 & 9223372036854775807;
  x_3 = VIEW_CONVERT_EXPR<double>(ix.1_4);
  return x_3;

so the issue might be as "simple" as that GIMPLE doesn't allow bit operations
on FP operands.

Which makes it a RTL missed optimization (to (and:DF ...)):

(set (reg:DF 90 [ <retval> ])
    (subreg:DF (and:DI (subreg:DI (reg/v:DF 91 [ x ]) 0)
            (const_int 9223372036854775807 [0x7fffffffffffffff])) 0))

unless RTL has the same restriction.

And/or at target missed optimization in case it doesn't provide a AND
instruction
on DFmode (it doesn't as far as I can see).