extractps selected too eagerly

[llvmbot]

Bugzilla Link	2647
Resolution	FIXED
Resolved on	Oct 31, 2008 09:44
Version	unspecified
OS	Windows NT
Reporter	LLVM Bugzilla Contributor
CC	@sunfishcode,@nlewycky

Extended Description

The following LLVM IR compiles to suboptimal code on x86 CPUs with SSE4 support, but optimizes fine on older CPUs:

external global float, align 16 ; <float*>:0 [#uses=2]

define internal void @""() {
load float* @​0, align 16 ; :1 [#uses=1]
insertelement <4 x float> undef, float %1, i32 0 ; <<4 x float>>:2 [#uses=1]
call <4 x float> @​llvm.x86.sse.rsqrt.ss( <4 x float> %2 ) ; <<4 x float>>:3 [#uses=1]
extractelement <4 x float> %3, i32 0 ; :4 [#uses=1]
store float %4, float* @​0, align 16
ret void
}

declare <4 x float> @​llvm.x86.sse.rsqrt.ss(<4 x float>) nounwind readnone

Here's the result on a Penryn CPU:

push ebp
mov ebp,esp
and esp,0FFFFFFF0h
rsqrtss xmm0,dword ptr ds:[1762ED0h]
extractps eax, xmm0
movd xmm0,eax
movss dword ptr ds:[1762ED0h],xmm0
mov esp,ebp
pop ebp
ret

And this is the lovable code I get on Conroe:

rsqrtss xmm0,dword ptr ds:[1762ED0h]
movss dword ptr ds:[1762ED0h],xmm0
ret

Ignoring the stack setup for now, it looks like extractps is selected too eagerly for an extractelement v4f32, 0.

P.S: To quickly test with and without SSE4 support just force X86SSELevel to the desired value in X86Subtarget::AutoDetectSubtargetFeatures().

[sunfishcode]

Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065836.html

[nlewycky]

This testcase is failing on my box:

$ Debug/bin/llvm-as < test/CodeGen/X86/extractps.ll | Debug/bin/llc -mcpu=penryn

    .text
    .align  16
    .type   __unnamed_1_0,@function

__unnamed_1_0:
rsqrtss __unnamed_2_1, %xmm0
extractps $0, %xmm0, __unnamed_2_1
ret
.size __unnamed_1_0, .-__unnamed_1_0

    .section        .note.GNU-stack,"",@progbits

If you're wondering what my CPU is, I've got an AMD. Here's the full specs:

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 107
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5000+
stepping : 2
cpu MHz : 2613.389
cache size : 512 KB
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch
bogomips : 5228.84
TLB size : 1024 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc 100mhzsteps

[llvmbot]

Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080804/065836.html

Thanks! It fixes only half the issue though. movss is two bytes shorter than extractps, so it should preferably be selected for any extractelement v4f32, 0. Furthermore, movss has a latency of 1 and throughput of 1/3, while extractps has a latency of 5 and throughput of just 1.

[llvmbot]

This testcase is failing on my box:

The testcase assumes/forces the target CPU to be an Intel Penryn (with SSE4.1 support). Your Athlon X2 doesn't support SSE4.1 so it should indeed crash. The code you're getting looks fine (aside from movss being more effienct than extractps).

[nlewycky]

The testcase isn't running the resulting code. If you specify penryn CPU, it should turn on SSE 4.1 and emit the code that matches the grep that's being run, and my host CPU shouldn't enter into it.

[sunfishcode]

The grep line in the test was too simple and ended up failing on
non-Darwin ABIs. I've now fixed it to be more specific, and to be
less sensitive to ABI differences.

[lattner]

Dan, is this fixed?

[llvmbot]

Dan, is this fixed?

It's not (r58379). The movd instruction is no longer generated, but extractps is still used where movss would have been both smaller and faster:

push ebp
mov ebp,esp
and esp,0FFFFFFF0h
rsqrtss xmm0,dword ptr ds:[1762ED0h]
extractps dword ptr ds:[1762ED0h],xmm0,0
mov esp,ebp
pop ebp
ret

It's also a mystery to me why it does all the stack setup while on older processors it's just three instrutions...

[sunfishcode]

With this commit:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20081027/069165.html
codegen avoids selecting extractps for a store of element 0, and uses movss instead.
The provided testcase now compiles to three instructions even with -mcpu=penryn.

The extra setup is a known issue. The code that decides if stack-pointer alignment
is necessary is over-conservative in some cases. See lib/Target/X86/README-SSE.txt,
the entry starting with "LLVM currently generates stack realignment code".

Thanks!

[llvmbot]

Thanks a lot Dan!