[Bug target/95083] New: x86 fp_movcc expansion depends on real_cst sharing
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue May 12 13:41:08 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95083
Bug ID: 95083
Summary: x86 fp_movcc expansion depends on real_cst sharing
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
I see gcc.target/i386/avxfp-1.c FAILing, which is
double x;
void
t()
{
x=x>5?x:5;
}
double x;
void
q()
{
x=x<5?x:5;
}
and q() recognized as FP min by ix86_expand_fp_movcc because the doesn't
pass prepare_cmp_insn () and later ifcvt matches up the originally
distinct pseudos for the two mentions of '5'. For t() prepare_cmp_insn ()
succeeeds and ix86_expand_fp_movcc expands this to a UNSPEC_BLEND
(because the two mentions of '5' get a different pseudo so this doesn't
look like a max). The first prepare_cmp_insn fails because it is fed
(lt (reg:DF 82 [ x.3_1 ])
(const_double:DF 5.0e+0 [0x0.ap+3]))
and appearantly we cannot do a lt compare(?) (but later during ifcvt we can).
Note the above is when expanding from a COND_EXPR, thus
t ()
{
double x.1_1;
double iftmp.0_3;
;; basic block 2, loop depth 0
;; pred: ENTRY
x.1_1 = x;
iftmp.0_3 = x.1_1 > 5.0e+0 ? x.1_1 : 5.0e+0;
x = iftmp.0_3;
return;
and
q ()
{
double x.3_1;
double iftmp.2_3;
;; basic block 2, loop depth 0
;; pred: ENTRY
x.3_1 = x;
iftmp.2_3 = x.3_1 < 5.0e+0 ? x.3_1 : 5.0e+0;
x = iftmp.2_3;
return;
similar FAILs occur for
FAIL: gcc.target/i386/avxfp-1.c scan-assembler vmaxsd
FAIL: gcc.target/i386/avxfp-2.c scan-assembler vminsd
FAIL: gcc.target/i386/ssefp-1.c scan-assembler maxsd
FAIL: gcc.target/i386/ssefp-2.c scan-assembler minsd
So what's missing is simplification of
Trying 8 -> 9:
8: r87:DF=r85:DF<r82:DF
9: r84:DF=unspec[r85:DF,r82:DF,r87:DF] 105
REG_DEAD r87:DF
REG_DEAD r85:DF
REG_DEAD r82:DF
Failed to match this instruction:
(set (reg:DF 84)
(unspec:DF [
(reg:DF 85)
(reg:DF 82 [ x.1_1 ])
(lt:DF (reg:DF 85)
(reg:DF 82 [ x.1_1 ]))
] UNSPEC_BLENDV))
to UNSPEC_MIN/MAX I guess?
More information about the Gcc-bugs
mailing list