[Bug target/97822] [13/14/15/16 Regression] internal compiler error: in choose_baseaddr

[werner.zeh at coreboot dot org]

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

--- Comment #26 from Werner Zeh <werner.zeh at coreboot dot org> ---
(In reply to Uroš Bizjak from comment #15)
> Hm, the generated code does not look right:
> 
> _Z1hv:
> 	pushq	%rbp
> 	.seh_pushreg	%rbp
> 	pushq	%rdi
> 	.seh_pushreg	%rdi
> 	pushq	%rsi
> 	.seh_pushreg	%rsi
> 	subq	$160, %rsp
> 	.seh_stackalloc	160
> 	andq	$-16, %rsp
> (*)->	leaq	(%rsp), %rbp
> 	.seh_setframe	%rbp, 0
> 	movups	%xmm6, 0(%rbp)
> 	.seh_savexmm	%xmm6, 0
> 	movups	%xmm7, 16(%rbp)
> 	.seh_savexmm	%xmm7, 16
> 	movups	%xmm8, 32(%rbp)
> 	.seh_savexmm	%xmm8, 32
> 	movups	%xmm9, 48(%rbp)
> 	.seh_savexmm	%xmm9, 48
> 	movups	%xmm10, 64(%rbp)
> 	.seh_savexmm	%xmm10, 64
> 	movups	%xmm11, 80(%rbp)
> 	.seh_savexmm	%xmm11, 80
> 	movups	%xmm12, 96(%rbp)
> 	.seh_savexmm	%xmm12, 96
> 	movups	%xmm13, 112(%rbp)
> 	.seh_savexmm	%xmm13, 112
> 	movups	%xmm14, 128(%rbp)
> 	.seh_savexmm	%xmm14, 128
> 	movups	%xmm15, 144(%rbp)
> 	.seh_savexmm	%xmm15, 144
> 	.seh_endprologue
> 	call	_Z1fv
> 	nop
> 	movaps	(%rsp), %xmm6
> 	movaps	16(%rsp), %xmm7
> 	movaps	32(%rsp), %xmm8
> 	movaps	48(%rsp), %xmm9
> 	movaps	64(%rsp), %xmm10
> 	movaps	80(%rsp), %xmm11
> 	movaps	96(%rsp), %xmm12
> 	movaps	112(%rsp), %xmm13
> 	movaps	128(%rsp), %xmm14
> 	movaps	144(%rsp), %xmm15
> (**)->	leaq	160(%rbp), %rsp
> 	popq	%rsi
> 	popq	%rdi
> 	popq	%rbp
> 	ret
> 
> Please note that at (*) RBP gets assigned the value of realigned RSP. At
> (**) RSP gets assigned the value of RBP + 160, but RBP here holds the value
> of realigned RSP. This will misaling the stack for follow-up POP
> instructions.

Hi Uros,

the observed stack pointer alignment issues are not introduced by the proposed
fix but were introduced by commit 074226d5aa86cd3de517014acfe34c7f69a2ccc7. It
is even worse because the RSP restoration happens on base of RBP but RBP was
aligned already earlier. This means the subsequent POP operations can only
succeed if the initial RSP value was already aligned.

Further on, the obvious asymmetry in the prolog (all based on RBP) and the
epilog (all based on RSP) seem quite odd to me. In addition, it is strange that
the XMM save operations happens unaligned [movups %xmm6, 0(%rbp)] while the RBP
is already aligned. In the epilog, aligned restore happens [movaps (%rsp),
%xmm6].

So I guess that my patch is not wrong but not sufficient at all.

What do you think?