From 11b6dfb970c65fe2a9b91f3e1242cf2ecdfe5226 Mon Sep 17 00:00:00 2001 From: JF Bastien Date: Wed, 4 Mar 2020 13:51:35 -0800 Subject: [PATCH] Test that volatile load type isn't changed 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 --- docs/LangRef.rst | 9 +-- .../InstCombine/volatile_load_cast.ll | 59 +++++++++++++++++++ 2 files changed, 64 insertions(+), 4 deletions(-) create mode 100644 test/Transforms/InstCombine/volatile_load_cast.ll diff --git a/docs/LangRef.rst b/docs/LangRef.rst index 5ad97fb8726..480a0fc4c07 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -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 diff --git a/test/Transforms/InstCombine/volatile_load_cast.ll b/test/Transforms/InstCombine/volatile_load_cast.ll new file mode 100644 index 00000000000..7eb0a5427c9 --- /dev/null +++ b/test/Transforms/InstCombine/volatile_load_cast.ll @@ -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 +}