c486b82cfb
This is a retry of b4b97ec813 - that was reverted because it
could cause miscompiles by illegally reordering memory operations.
A new test based on #53695 is added here to verify we do not have
that same problem.
extract_vec_elt (load X), C --> scalar load (X+C)
As noted in the comment, DAGCombiner has this fold -- and the code in this
patch is adapted from DAGCombiner::scalarizeExtractedVectorLoad() -- but
x86 should benefit even if the loaded vector has other uses as long as we
apply some other x86-specific conditions. The motivating example from #50310
is shown in vec_int_to_fp.ll.
Fixes #50310
Fixes #53695
Differential Revision: https://reviews.llvm.org/D118376
27 lines
875 B
LLVM
27 lines
875 B
LLVM
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
|
|
; RUN: llc -mtriple=x86_64-unknown -mattr=-sse4.2,+sse4.1 < %s | FileCheck %s
|
|
|
|
; Make sure we don't load from the location pointed to by %p
|
|
; twice: it has non-obvious performance implications, and
|
|
; the relevant transformation doesn't know how to update
|
|
; the chains correctly.
|
|
; PR10747
|
|
|
|
define <4 x i32> @test(<4 x i32>* %p) {
|
|
; CHECK-LABEL: test:
|
|
; CHECK: # %bb.0:
|
|
; CHECK-NEXT: cmpl $3, 8(%rdi)
|
|
; CHECK-NEXT: je .LBB0_1
|
|
; CHECK-NEXT: # %bb.2:
|
|
; CHECK-NEXT: xorps %xmm0, %xmm0
|
|
; CHECK-NEXT: retq
|
|
; CHECK-NEXT: .LBB0_1:
|
|
; CHECK-NEXT: movaps (%rdi), %xmm0
|
|
; CHECK-NEXT: retq
|
|
%v = load <4 x i32>, <4 x i32>* %p
|
|
%e = extractelement <4 x i32> %v, i32 2
|
|
%cmp = icmp eq i32 %e, 3
|
|
%sel = select i1 %cmp, <4 x i32> %v, <4 x i32> zeroinitializer
|
|
ret <4 x i32> %sel
|
|
}
|