[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-11 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #8 from Richard Biener  ---
The problem of sel-sched propagating hard-regs is likely older, thus P2 since
this is also not from a real-world program that newly fails to build.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-10 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

--- Comment #7 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #3)
> Why does sel-sched try to propagate hard registers into insns before RA? 
> The whole point of the combiner changes was not to do that, so that the RA
> can do better job.

That, and *correctness*.  Propagating hard registers can lead to things that
cannot be reloaded.  Even in the simple case here you cannot necessarily
replace the hard reg with a pseudo and end up with valid code.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

Jakub Jelinek  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
CCing Segher and Vlad on this if they want to comment on that further.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

--- Comment #5 from Jakub Jelinek  ---
It is not a matter of efficiency, but primarily that RA can't do anything in
many cases after propagating hard registers into instructions.  This PR is just
one of the many cases.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-10 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

--- Comment #4 from Alexander Monakov  ---
Well, often sel-sched just does not discriminate hardregs and pseudos when
checking if renaming/substitution may be applied. Sure, as a matter of
efficiency we should probably disallow substitution through such mixed
pseudo=hardreg assignments.

Nevertheless, if it's not only a matter of optimization, but also of internal
consistency, then I'd like to understand it better. Hence the question in
comment #2.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-10 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

--- Comment #3 from Jakub Jelinek  ---
Why does sel-sched try to propagate hard registers into insns before RA?  The
whole point of the combiner changes was not to do that, so that the RA can do
better job.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-09 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

--- Comment #2 from Alexander Monakov  ---
We have a pseudo:SI<-hardreg:SI assignment followed by
pseudo:DF<-float(pseudo:SI) conversion, and we substitute the latter through
the former, creating a pseudo:DF<-float(hardreg:SI) insn that fails in recog.

I'm not exactly sure why RA would reject reloading the operand when it's a
hardreg, but happily reload when it's a pseudo. Am I missing something obvious,
or are such constraints written down somewhere?

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-08 Thread ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

UroŇ° Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-08
 Ever confirmed|0   |1

--- Comment #1 from UroŇ° Bizjak  ---
The pattern of the offending instruction is defined as

(define_insn "*float2"
  [(set (match_operand:MODEF 0 "register_operand" "=f,v,v")
(float:MODEF
  (match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]

since RA is nowadays able to reload input operand of alternative 0:

(insn 17 35 15 2 (set (reg:DF 95)
(float:DF (reg:SI 98))) "pr90007.c":8:21 172 {*floatsidf2}
 (expr_list:REG_DEAD (reg:SI 98)
(nil)))

via memory:

(insn 17 35 37 2 (set (reg:DF 8 st [95])
(float:DF (mem/c:SI (plus:DI (reg/f:DI 7 sp)
(const_int -4 [0xfffc])) [1 %sfp+-4 S4 A32])))
"pr90007.c":8:21 172 {*floatsidf2}
 (nil))

sel-sched is not prepared for this, uses:

--cut here--
/* Estimate the cost of issuing INSN on DFA state STATE.  */
static int
estimate_insn_cost (rtx_insn *insn, state_t state)
{
  static state_t temp = NULL;
  int cost;

  if (!temp)
temp = xmalloc (dfa_state_size);

  memcpy (temp, state, dfa_state_size);
  cost = state_transition (temp, insn);

  if (cost < 0)
return 0;
  else if (cost == 0)
return 1;
  return cost;
}
--cut here--

that calls state_transition, which tries to calculate and verify constraints
via the following call sequence:

#4  0x0064ea7f in extract_constrain_insn_cached
(insn=insn@entry=0x7fffea669940) at ../../git/gcc/gcc/recog.c:2223
#5  0x01217c4f in get_attr_type (insn=insn@entry=0x7fffea669940) at
../../git/gcc/gcc/config/i386/i386.md:2288
#6  0x0124994c in internal_dfa_insn_code_bdver1 (insn=0x7fffea669940)
at ../../git/gcc/gcc/config/i386/i386.md:15343
#7  0x01233169 in dfa_insn_code (insn=0x27) at insn-automata.c:158875
#8  state_transition (state=0x21a7af0, insn=insn@entry=0x7fffea669940) at
insn-automata.c:27818

and crashes due to unmet constraints.

[Bug rtl-optimization/90007] [9 Regression] ICE in extract_constrain_insn_cached, at recog.c:2223

2019-04-08 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90007

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0