[Bug target/64897] Floating-point "and" not optimized on x86-64
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Feb 2 08:45:00 GMT 2015
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).
More information about the Gcc-bugs
mailing list