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

[dbabokin]

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

[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]

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

[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.

[llvmbot]

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

[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