This seems to have been added to prevent two 32-bit stores in older versions. But the latest version doesn't seem to use two 32-bit stores for casting. This increases the stack size and causes unnecessary bitcasting. Do we still need this?
Details
Details
- Reviewers
- None
Diff Detail
Diff Detail
Event Timeline
Comment Actions
Please update the tests in llvm/test/CodeGen/X86 along with the patch so reviewers can make decision.
Comment Actions
I applied the patch myself and checked the tests. After this change we do 2 stores as the comment says we would
See comments below
diff --git a/llvm/test/CodeGen/X86/uint64-to-float.ll b/llvm/test/CodeGen/X86/uint64-to-float.ll index 8b6623476eba..b1de2b7ec005 100644 --- a/llvm/test/CodeGen/X86/uint64-to-float.ll +++ b/llvm/test/CodeGen/X86/uint64-to-float.ll @@ -13,12 +13,13 @@ define float @test(i64 %a) nounwind { ; X86-NEXT: movl %esp, %ebp ; X86-NEXT: andl $-8, %esp ; X86-NEXT: subl $16, %esp -; X86-NEXT: movl 12(%ebp), %eax -; X86-NEXT: movsd {{.*#+}} xmm0 = mem[0],zero -; X86-NEXT: movlps %xmm0, {{[0-9]+}}(%esp). <- single f64 store -; X86-NEXT: shrl $31, %eax +; X86-NEXT: movl 8(%ebp), %eax +; X86-NEXT: movl 12(%ebp), %ecx +; X86-NEXT: movl %ecx, {{[0-9]+}}(%esp). <- store 1 +; X86-NEXT: movl %eax, {{[0-9]+}}(%esp) <- store 2 +; X86-NEXT: shrl $31, %ecx ; X86-NEXT: fildll {{[0-9]+}}(%esp) -; X86-NEXT: fadds {{\.?LCPI[0-9]+_[0-9]+}}(,%eax,4) +; X86-NEXT: fadds {{\.?LCPI[0-9]+_[0-9]+}}(,%ecx,4) ; X86-NEXT: fstps {{[0-9]+}}(%esp) ; X86-NEXT: movss {{.*#+}} xmm0 = mem[0],zero,zero,zero ; X86-NEXT: movss %xmm0, (%esp)
Comment Actions
You're right, I should have checked enough before request a review.
Sorry for confusion.