[Bug middle-end/79514] [5/6/7 Regression] ICE in curr_insn_transform, at lra-constraints.c:3773

[ubizjak at gmail dot com]

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

--- Comment #10 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 40868 [details]
> gcc7-pr79514.patch
> 
> You mean like this?  That certainly works for x86, but I'm afraid it is
> going to break or penalize various other arches.
> The thing is, HAVE_PRE_MODIFY_DISP is set to 1 only on 5 targets, but quick
> grep reveals that there are many more targets that somehow handle pre_modify
> or have insn patterns using that.  This is not unlike HAVE_PRE_DEC and
> similar, x86 also doesn't claim it has HAVE_PRE_DEC, yet it uses it for
> pushes.
> So I think pushxf1 expander in i386.md is the way to go.

Years ago, I defined HAVE_PRE_DEC, and I was told that it is intended for
targets that can increment pointer on *any* memory access, not just on stack
pointer. So, x86 uses PRE_DEC and POST_INC only to abstract push and pop insn.
Various parts of the compiler (modulo auto-inc-dec.c) mostly check for PRE_DEC
and POST_INC to skip further optimizations, which is non-issue for push and
pop.

But this generic part of the code assumes that any target can handle
PRE_MODIFY, and emits insn even for !HAVE_PRE_MODIFY_DISP. This is
conservatively incorrect, so conditionally disabling the part that blindly
emits PRE_MODIFY is IMO the way to go.

Maybe this issue should be discussed on the ML.

BTW:

-      dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
-                               gen_int_mode (offset, Pmode));
+      if (offset)
+       dest_addr = gen_rtx_PLUS (Pmode, stack_pointer_rtx,
+                                 gen_int_mode (offset, Pmode));
+      else
+       dest_addr = stack_pointer_rtx;

plus_constant?