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?
