Bad code generation with r128175

[efriedma-quic]

Bugzilla Link	9539
Resolution	FIXED
Resolved on	Oct 09, 2013 15:53
Version	unspecified
OS	Linux
CC	@atrick

Extended Description

Testcase:
#include <stdio.h>
typedef __int128_t x;
__attribute((noinline)) int a(x i, x j, int *p, int z) {
int k = i>j;
int l = (k?11:111)/z;
asm volatile ("" :::"memory", "rcx", "rax", "rdx", "rbx", "rsi", "rdi", "rbp", "r9", "r10", "r11", "r12", "r13", "r14", "r15");
*p = l;
if (k) return 201/z;
return 0;
}
int main() {
int x;
printf("%d\n", a(1, 0, &x, 1));
}

The compiled program built with clang crashes on x86-64 Linux. The issue is that the code generated to spill EFLAGS corrupts values spilled into the red zone.

[atrick]

If we're not interested in improving EFLAGS spilling in general, then we could simply record or check for the fact that push/pop have been used before optimizing the current frame as a leaf call. In this case just force SP to be adjusted in the prolog/epilog.

[efriedma-quic]

Note that it is possible to write IR which causes EFLAGS to be spilled on unpatched trunk:

define void @​f(i256* nocapture %a, i256* nocapture %b, i256* nocapture %cc,i256* nocapture %dd) nounwind uwtable noinline ssp {
entry:
%c = load i256* %cc
%d = load i256* %dd
%add = add nsw i256 %c, %d
store i256 %add, i256* %a, align 8
%or = or i256 %c,
1606938044258990275541962092341162602522202993782792835301376
%add6 = add nsw i256 %or, %d
store i256 %add6, i256* %b, align 8
ret void
}

[atrick]

Fixed by nrotem in r170961.