[PATCH] D75644: Test that volatile load type isn't changed

[JF Bastien via Phabricator via llvm-commits]

jfb created this revision.
jfb added a reviewer: lebedev.ri.
Herald added subscribers: llvm-commits, ributzka, dexonsmith, jkorous.
Herald added a project: LLVM.

As discussed in D75505 <https://reviews.llvm.org/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.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D75644

Files:
  llvm/docs/LangRef.rst
  llvm/test/Transforms/InstCombine/volatile_load_cast.ll


Index: llvm/test/Transforms/InstCombine/volatile_load_cast.ll
===================================================================
--- /dev/null
+++ llvm/test/Transforms/InstCombine/volatile_load_cast.ll
@@ -0,0 +1,21 @@
+; RUN: opt < %s -instcombine -S | FileCheck %s
+
+define float @float_load(i32* %addr) {
+; CHECK-LABEL: @float_load(
+; CHECK:         %int = load volatile i32, i32* %addr, align 4
+; CHECK-NEXT:    %float = bitcast i32 %int to float
+; CHECK-NEXT:    ret float %float
+  %int = load volatile i32, i32* %addr, align 4
+  %float = bitcast i32 %int to float
+  ret float %float
+}
+
+define i32 @int_load(float* %addr) {
+; CHECK-LABEL: @int_load(
+; CHECK:         %float = load volatile float, float* %addr, align 4
+; CHECK-NEXT:    %int = bitcast float %float to i32
+; CHECK-NEXT:    ret i32 %int
+  %float = load volatile float, float* %addr, align 4
+  %int = bitcast float %float to i32
+  ret i32 %int
+}
Index: llvm/docs/LangRef.rst
===================================================================
--- llvm/docs/LangRef.rst
+++ llvm/docs/LangRef.rst
@@ -2456,10 +2456,11 @@
 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
 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D75644.248308.patch
Type: text/x-patch
Size: 1868 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200304/654bff6b/attachment-0001.bin>