https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79514
--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Jakub Jelinek from comment #7) > (In reply to Uroš Bizjak from comment #6) > > (In reply to Uroš Bizjak from comment #5) > > > Maybe we should use our own pushxf expander? > > > > No. Middle end should be fixed. x86 does not define any of HAVE_PRE_MODIFY > > macros. > > So what it can emit? PRE_DEC is not really right, because GET_MODE_SIZE > (XFmode) is in that case 12, but PUSH_ROUNDING increases that to 16. But > the push actually needs to adjust sp by 16, not 12. > With -m128bit-long-double, rounded_size is equal to GET_MODE_SIZE and we get > to: > 4124 if (GET_MODE_SIZE (mode) == rounded_size) > 4125 dest_addr = gen_rtx_fmt_e (STACK_PUSH_CODE, Pmode, > stack_pointer_rtx); > I think i386.md should have a pushxf1 expander enabled at least for the case > when GET_MODE_SIZE (XFmode) != PUSH_ROUNDING (GET_MODE_SIZE (XFmode)) and > just not use PRE_DEC in the pattern at all, just sp subtraction plus store. Just below the code you quoted is some fixup code, depending on FUNCTION_ARG_PADDING () == downward. I wonder, why similar fixup can't be also applied for upward padding (the referred code)? The proposed XFmode expander would do just that - adjust the stack pointer reg and move the value to adjusted position, as is already the case with a similar x86 splitter (... which, according to its %%% comment, is a workaround by itself and should be killed). So, while introducing expander would solve this particular problem for x86, it would leave other targets unfixed. IMO, this problem should be fixed in the middle-end, not worked around with long-lasting target workarounds.
