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?
