Spilled XMM is assumed wrongly to be aligned

[llvmbot]

Bugzilla Link	14646
Version	trunk
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@asl,@dbabokin,@darkbuck

Extended Description

With XMM, loading m in INSTrm should be 16-byte aligned.

    xorps   (%esp), %xmm0           # 16-byte Folded Reload

But This function does not have realignment in prologue. (%esp) might not be 16-aligned.

It causes miscompilation with i686-cygwin vectorizer.

• Reproducible for i686-freebsd (also possible for netbsd, cygming and win32)
• It's leaf function. This issue could be suppressed if frame pointer were generated.

/* testcase.c */
typedef long long W attribute((vector_size(16)));
W foo(W a0) {
W r0;
asm volatile("nop":"=x"(r0)::"%xmm1","%xmm2","%xmm3","xmm4","%xmm5","%xmm6","%xmm7");
return a0 ^ r0;
}

llc -mtriple=i686-freebsd -mattr=-avx

foo: # @​foo

BB#0: # %entry

    subl    $28, %esp
    movups  %xmm0, (%esp)           # 16-byte Folded Spill
    #APP
    nop
    #NO_APP
    xorps   (%esp), %xmm0           # 16-byte Folded Reload
    addl    $28, %esp
    ret

[lattner]

The X86 backend knows how to do stack realignment, it probably just thinks that freebsd has a 16-byte aligned stack (like linux).

-Chris

[llvmbot]

It is using movups for the spill, though, rather than movaps as i686-linux does.

[llvmbot]

I think the problem is that the reload and xor are being fused in X86InstrInfo::foldMemoryOperandImpl() without verifying and/or specifying the alignment that would be required.

[dbabokin]

*** Bug llvm/llvm-bugzilla-archive#16126 has been marked as a duplicate of this bug. ***

[dbabokin]

The allocated stack frame slot is marked as 16-byte aligned in my case (while stack is 4 byte aligned):

*** IR Dump After Virtual Register Rewriter ***:

Machine code for function f_fu: Post SSA

Frame Objects:
fi#-3: size=4, align=4, fixed, at location [SP+12]
fi#-2: size=4, align=4, fixed, at location [SP+8]
fi#-1: size=4, align=4, fixed, at location [SP+4]
fi#0: size=16, align=16, at location [SP+4] <<<<<<<<<<<<<<<< here's it.

So it's probably not X86InstrInfo::foldMemoryOperandImpl(), which needs to be fixed, but slot needs to be allocated at aligned boundary as declared.

Or if X86InstrInfo::foldMemoryOperandImpl() needs to be fix, then also slot needs to be created as 4 bytes aligned.

[dbabokin]

mentioned in issue llvm/llvm-bugzilla-archive#16126