RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-26 04:40:38 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Test that volatile load type isn't changed

Browse Source 
Summary: As discussed in D75505, it's not particularly useful to change the type of a load to/from floating-point/integer because it's followed by a bitcast, and it might lead to surprising code generation. Check that this doesn't generally happen.

Reviewers: lebedev.ri

Subscribers: jkorous, dexonsmith, ributzka, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D75644
This commit is contained in:
JF Bastien 2020-03-04 13:51:35 -08:00
parent 31973e0dfa
commit 11b6dfb970
2 changed files with 64 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/LangRef.rst
View File

@ -2456,10 +2456,11 @@ The compiler may assume execution will continue after a volatile operation,
so operations which modify memory or may have undefined behavior can be
hoisted past a volatile operation.
IR-level volatile loads and stores cannot safely be optimized into
llvm.memcpy or llvm.memmove intrinsics even when those intrinsics are
flagged volatile. Likewise, the backend should never split or merge
target-legal volatile load/store instructions.
IR-level volatile loads and stores cannot safely be optimized into llvm.memcpy
or llvm.memmove intrinsics even when those intrinsics are flagged volatile.
Likewise, the backend should never split or merge target-legal volatile
load/store instructions. Similarly, IR-level volatile loads and stores cannot
change from integer to floating-point or vice versa.
.. admonition:: Rationale

59
test/Transforms/InstCombine/volatile_load_cast.ll Normal file
View File

@ -0,0 +1,59 @@
; RUN: opt < %s -instcombine -S | FileCheck %s
; Ensure that volatile loads followed by a bitcast don't get transformed into a
; volatile load of the bitcast-target type. This is unlikely to provide much in
; terms of optimizations, and might break the programmer's expectation for code
; generation, however brittle that expectation might be.
;
; See llvm.org/D75644 and llvm.org/D75505
target datalayout = "e-p:64:64-i32:32:32-i64:64:64-f32:32:32-f64:64:64"
define float @float_load(i32* %addr) {
; CHECK-LABEL: @float_load(
; CHECK: %i32 = load volatile i32, i32* %addr, align 4
; CHECK-NEXT: %float = bitcast i32 %i32 to float
; CHECK-NEXT: ret float %float
%i32 = load volatile i32, i32* %addr, align 4
%float = bitcast i32 %i32 to float
ret float %float
}
define i32 @i32_load(float* %addr) {
; CHECK-LABEL: @i32_load(
; CHECK: %float = load volatile float, float* %addr, align 4
; CHECK-NEXT: %i32 = bitcast float %float to i32
; CHECK-NEXT: ret i32 %i32
%float = load volatile float, float* %addr, align 4
%i32 = bitcast float %float to i32
ret i32 %i32
}
define double @double_load(i64* %addr) {
; CHECK-LABEL: @double_load(
; CHECK: %i64 = load volatile i64, i64* %addr, align 8
; CHECK-NEXT: %double = bitcast i64 %i64 to double
; CHECK-NEXT: ret double %double
%i64 = load volatile i64, i64* %addr, align 8
%double = bitcast i64 %i64 to double
ret double %double
}
define i64 @i64_load(double* %addr) {
; CHECK-LABEL: @i64_load(
; CHECK: %double = load volatile double, double* %addr, align 8
; CHECK-NEXT: %i64 = bitcast double %double to i64
; CHECK-NEXT: ret i64 %i64
%double = load volatile double, double* %addr, align 8
%i64 = bitcast double %double to i64
ret i64 %i64
}
define i8* @ptr_load(i64* %addr) {
; CHECK-LABEL: @ptr_load(
; CHECK: %i64 = load volatile i64, i64* %addr, align 8
; CHECK-NEXT: %ptr = inttoptr i64 %i64 to i8*
; CHECK-NEXT: ret i8* %ptr
%i64 = load volatile i64, i64* %addr, align 8
%ptr = inttoptr i64 %i64 to i8*
ret i8* %ptr
}