mirror of
https://github.com/RPCS3/llvm-mirror.git
synced 2025-02-01 05:01:59 +01:00
594dcaeec7
When writing an email for a follow up proposal, I realized one of the diffs in the committed change was incorrect. Digging into it revealed that the fix is complicated enough to require some thought, so reverting in the meantime.
The problem is visible in this diff (from the revert):
; X64-SSE-LABEL: store_fp128:
; X64-SSE: # %bb.0:
-; X64-SSE-NEXT: movaps %xmm0, (%rdi)
+; X64-SSE-NEXT: subq $24, %rsp
+; X64-SSE-NEXT: .cfi_def_cfa_offset 32
+; X64-SSE-NEXT: movaps %xmm0, (%rsp)
+; X64-SSE-NEXT: movq (%rsp), %rsi
+; X64-SSE-NEXT: movq {{[0-9]+}}(%rsp), %rdx
+; X64-SSE-NEXT: callq __sync_lock_test_and_set_16
+; X64-SSE-NEXT: addq $24, %rsp
+; X64-SSE-NEXT: .cfi_def_cfa_offset 8
; X64-SSE-NEXT: retq
store atomic fp128 %v, fp128* %fptr unordered, align 16
ret void
The problem here is three fold:
1) x86-64 doesn't guarantee atomicity of anything larger than 8 bytes. Some platforms observably break this guarantee, others don't, but the codegen isn't considering this, so it's wrong on at least some platforms.
2) When I started to track down the problem, I discovered that DAGCombiner had stripped the atomicity off the store entirely. This comes down to idiomatic usage of DAG.getStore passing all MMO components separately as opposed to just passing the MMO.
3) On x86 (not -64), there are cases where 8 byte atomiciy is supported, but only for floating point operations. This would seem to imply that operation typing matters for correctness, and DAGCombine happily folds away bitcasts. I'm not 100% sure there's a problem here, but I'm not entirely sure there isn't either.
I plan on returning to each issue in turn; sorry for the churn here.
36 lines
1.5 KiB
LLVM
36 lines
1.5 KiB
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc < %s -mtriple=x86_64-linux-generic -verify-machineinstrs -mattr=-sse | FileCheck %s --check-prefix=X64-NOSSE
|
|
; RUN: llc < %s -mtriple=x86_64-linux-generic -verify-machineinstrs | FileCheck %s --check-prefix=X64-SSE
|
|
|
|
; Note: This test is testing that the lowering for atomics matches what we
|
|
; currently emit for non-atomics + the atomic restriction. The presence of
|
|
; particular lowering detail in these tests should not be read as requiring
|
|
; that detail for correctness unless it's related to the atomicity itself.
|
|
; (Specifically, there were reviewer questions about the lowering for halfs
|
|
; and their calling convention which remain unresolved.)
|
|
|
|
define void @store_fp128(fp128* %fptr, fp128 %v) {
|
|
; X64-NOSSE-LABEL: store_fp128:
|
|
; X64-NOSSE: # %bb.0:
|
|
; X64-NOSSE-NEXT: pushq %rax
|
|
; X64-NOSSE-NEXT: .cfi_def_cfa_offset 16
|
|
; X64-NOSSE-NEXT: callq __sync_lock_test_and_set_16
|
|
; X64-NOSSE-NEXT: popq %rax
|
|
; X64-NOSSE-NEXT: .cfi_def_cfa_offset 8
|
|
; X64-NOSSE-NEXT: retq
|
|
;
|
|
; X64-SSE-LABEL: store_fp128:
|
|
; X64-SSE: # %bb.0:
|
|
; X64-SSE-NEXT: subq $24, %rsp
|
|
; X64-SSE-NEXT: .cfi_def_cfa_offset 32
|
|
; X64-SSE-NEXT: movaps %xmm0, (%rsp)
|
|
; X64-SSE-NEXT: movq (%rsp), %rsi
|
|
; X64-SSE-NEXT: movq {{[0-9]+}}(%rsp), %rdx
|
|
; X64-SSE-NEXT: callq __sync_lock_test_and_set_16
|
|
; X64-SSE-NEXT: addq $24, %rsp
|
|
; X64-SSE-NEXT: .cfi_def_cfa_offset 8
|
|
; X64-SSE-NEXT: retq
|
|
store atomic fp128 %v, fp128* %fptr unordered, align 16
|
|
ret void
|
|
}
|