[Bug target/84844] [8 Regression] ICE in extract_constrain_insn_cached, at recog.c:2217 (error: insn does not satisfy its constraints)
jakub at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Mar 13 11:50:00 GMT 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84844
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The problem is that if a constraint returns NO_REGS before RA (i.e. in
non-strict mode) then that alternative is ignored, and e.g. get_attr_type used
by sched1 needs to compute alternative. As the instruction uses
nonimmediate_operand and the only alternative with "r" input has "Yc" output
which is NO_REGS for this -march=, if the operand is a register, there is no
alternative left.
The following patch fixes this for me:
--- gcc/config/i386/i386.md.jj 2018-03-13 09:05:22.480987994 +0100
+++ gcc/config/i386/i386.md 2018-03-13 12:44:21.372058947 +0100
@@ -5325,16 +5325,17 @@
})
(define_insn "*float<SWI48:mode><MODEF:mode>2_mixed"
- [(set (match_operand:MODEF 0 "register_operand" "=f,Yc,v")
+ [(set (match_operand:MODEF 0 "register_operand" "=f,Yc,v,!???v")
(float:MODEF
- (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
+ (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m,r")))]
"SSE_FLOAT_MODE_P (<MODEF:MODE>mode) && TARGET_SSE_MATH"
"@
fild%Z1\t%1
%vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}
+ %vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}
%vcvtsi2<MODEF:ssemodesuffix><SWI48:rex64suffix>\t{%1, %d0|%d0, %1}"
- [(set_attr "type" "fmov,sseicvt,sseicvt")
- (set_attr "prefix" "orig,maybe_vex,maybe_vex")
+ [(set_attr "type" "fmov,sseicvt,sseicvt,sseicvt")
+ (set_attr "prefix" "orig,maybe_vex,maybe_vex,maybe_vex")
(set_attr "mode" "<MODEF:MODE>")
(set (attr "prefix_rex")
(if_then_else
@@ -5342,11 +5343,11 @@
(match_test "<SWI48:MODE>mode == DImode"))
(const_string "1")
(const_string "*")))
- (set_attr "unit" "i387,*,*")
- (set_attr "athlon_decode" "*,double,direct")
- (set_attr "amdfam10_decode" "*,vector,double")
- (set_attr "bdver1_decode" "*,double,direct")
- (set_attr "znver1_decode" "double,*,*")
+ (set_attr "unit" "i387,*,*,*")
+ (set_attr "athlon_decode" "*,double,direct,double")
+ (set_attr "amdfam10_decode" "*,vector,double,vector")
+ (set_attr "bdver1_decode" "*,double,direct,double")
+ (set_attr "znver1_decode" "double,*,*,*")
(set_attr "fp_int_src" "true")
(set (attr "enabled")
(cond [(eq_attr "alternative" "0")
The CPU does support this insn, just it is very undesirable for tuning.
So, the !??? should tell reload to try very hard not to use that alternative.
More information about the Gcc-bugs
mailing list