e6ad9ef4e7
The basic idea to this is that a) having a single canonical type makes CSE easier, and b) many of our transforms are inconsistent about which types we end up with based on visit order. I'm restricting this to constants as for non-constants, we'd have to decide whether the simplicity was worth extra instructions. For constants, there are no extra instructions. We chose the canonical type as i64 arbitrarily. We might consider changing this to something else in the future if we have cause. Differential Revision: https://reviews.llvm.org/D115387
26 lines
767 B
LLVM
26 lines
767 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
|
|
; RUN: opt < %s -instcombine -S -o - | FileCheck %s
|
|
|
|
define i32 @a(<4 x i64> %I) {
|
|
; CHECK-LABEL: @a(
|
|
; CHECK-NEXT: [[TMP1:%.*]] = bitcast <4 x i64> [[I:%.*]] to <8 x i32>
|
|
; CHECK-NEXT: [[K:%.*]] = extractelement <8 x i32> [[TMP1]], i64 6
|
|
; CHECK-NEXT: ret i32 [[K]]
|
|
;
|
|
%J = trunc <4 x i64> %I to <4 x i32>
|
|
%K = extractelement <4 x i32> %J, i32 3
|
|
ret i32 %K
|
|
}
|
|
|
|
define i32 @b(<4 x float> %I) {
|
|
; CHECK-LABEL: @b(
|
|
; CHECK-NEXT: [[TMP1:%.*]] = extractelement <4 x float> [[I:%.*]], i64 3
|
|
; CHECK-NEXT: [[K:%.*]] = fptosi float [[TMP1]] to i32
|
|
; CHECK-NEXT: ret i32 [[K]]
|
|
;
|
|
%J = fptosi <4 x float> %I to <4 x i32>
|
|
%K = extractelement <4 x i32> %J, i32 3
|
|
ret i32 %K
|
|
}
|
|
|