[Bug target/85173] ICE in in extract_insn, at recog.c:2304 for -fstack-clash-protection on ARM

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to ktkachov from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > I wonder if we shouldn't do:
> > > --- gcc/explow.c	2018-01-03 21:21:39.012907765 +0100
> > > +++ gcc/explow.c	2018-04-04 08:58:04.716738887 +0200
> > > @@ -1625,6 +1625,7 @@ set_stack_check_libfunc (const char *lib
> > >  void
> > >  emit_stack_probe (rtx address)
> > >  {
> > > +  address = memory_address (word_mode, address);
> > >    if (targetm.have_probe_stack_address ())
> > >      emit_insn (targetm.gen_probe_stack_address (address));
> > >    else
> > > 
> > > because it is tedious to do that in every emit_stack_probe caller.  Wonder
> > > why all the other target happen to work even without something like that
> > > (ok, some targets allow signed 32-bit offsets and maybe we never generate
> > > larger offsets).
> > 
> > That's similar to what I've been testing. My patch uses validize_mem on the
> > MEM rtx before passing it down to the target.
> > I'll be posting it to gcc-patches later today
> 
> That won't fix targets that have probe_stack_address expander, which is
> rs6000, powerpcspe and ia64.  Looking at those, the first two use
> address_operand predicate and the last one register_operand, perhaps we need
> to use create_address_operand and maybe_legitimize_operand for that case?
> Perhaps instead of validize_mem we should use create_input_operand and
> maybe_legitimize_operand for the gen_stack_probe case too and just use
> validize_mem for the emit_move_insn case?

I see what you mean. However, probe_stack and probe_stack_address are not
optabs, they are just pattern names that have a gen_* function. So we can't
call maybe_legitimize_operand on it. Do you think they should be made into
proper optabs or is it not worth the hassle?