maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/pr22774.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

22 lines
823 B
LLVM
Raw Normal View History

[X86] Regenerate test. NFC. llvm-svn: 281099
2016-09-10 05:36:17 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
Fix line ending in test CodeGen/X86/pr22774.ll. NFC. Also, replaced line with 'target triple' with flag -mtriple on the RUN line. Removed the data layout string as it is not needed. llvm-svn: 231654
2015-03-09 23:02:01 +08:00
; RUN: llc -mtriple=x86_64-pc-linux-gnu -mattr=+avx < %s | FileCheck %s
[DAGCombine] Fix a bug in a BUILD_VECTOR combine When trying to convert a BUILD_VECTOR into a shuffle, we try to split a single source vector that is twice as wide as the destination vector. We can not do this when we also need the zero vector to create a blend. This fixes PR22774. Differential Revision: http://reviews.llvm.org/D8040 llvm-svn: 231219
2015-03-04 15:27:39 +08:00
[X86][test] Add explicit dso_local to definitions in ELF static relocation model tests TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions. Adding explicit dso_local makes these tests align with the clang -fno-pic behavior and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
2020-12-31 06:40:50 +08:00
@in = dso_local global <4 x i64> <i64 -1, i64 -1, i64 -1, i64 -1>, align 32
@out = dso_local global <2 x i64> zeroinitializer, align 16
[DAGCombine] Fix a bug in a BUILD_VECTOR combine When trying to convert a BUILD_VECTOR into a shuffle, we try to split a single source vector that is twice as wide as the destination vector. We can not do this when we also need the zero vector to create a blend. This fixes PR22774. Differential Revision: http://reviews.llvm.org/D8040 llvm-svn: 231219
2015-03-04 15:27:39 +08:00
[X86][test] Add explicit dso_local to definitions in ELF static relocation model tests TargetMachine::shouldAssumeDSOLocal currently implies dso_local for such definitions. Adding explicit dso_local makes these tests align with the clang -fno-pic behavior and allow the removal of the TargetMachine::shouldAssumeDSOLocal special case.
2020-12-31 06:40:50 +08:00
define dso_local i32 @_Z3foov() {
[X86] Regenerate test. NFC. llvm-svn: 281099
2016-09-10 05:36:17 +08:00
; CHECK-LABEL: _Z3foov:
[CodeGen] Unify MBB reference format in both MIR and debug output As part of the unification of the debug format and the MIR format, print MBB references as '%bb.5'. The MIR printer prints the IR name of a MBB only for block definitions. * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)->getNumber\(\)/" << printMBBReference(*\1)/g' * find . \( -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#" << ([a-zA-Z0-9_]+)\.getNumber\(\)/" << printMBBReference(\1)/g' * find . \( -name "*.txt" -o -name "*.s" -o -name "*.mir" -o -name "*.cpp" -o -name "*.h" -o -name "*.ll" \) -type f -print0 | xargs -0 sed -i '' -E 's/BB#([0-9]+)/%bb.\1/g' * grep -nr 'BB#' and fix Differential Revision: https://reviews.llvm.org/D40422 llvm-svn: 319665
2017-12-05 01:18:51 +08:00
; CHECK: # %bb.0: # %entry
[x86] allow vector load narrowing with multi-use values This is a long-awaited follow-up suggested in D33578. Since then, we've picked up even more opportunities for vector narrowing from changes like D53784, so there are a lot of test diffs. Apart from 2-3 strange cases, these are all wins. I've structured this to be no-functional-change-intended for any target except for x86 because I couldn't tell if AArch64, ARM, and AMDGPU would improve or not. All of those targets have existing regression tests (4, 4, 10 files respectively) that would be affected. Also, Hexagon overrides the shouldReduceLoadWidth() hook, but doesn't show any regression test diffs. The trade-off is deciding if an extra vector load is better than a single wide load + extract_subvector. For x86, this is almost always better (on paper at least) because we often can fold loads into subsequent ops and not increase the official instruction count. There's also some unknown -- but potentially large -- benefit from using narrower vector ops if wide ops are implemented with multiple uops and/or frequency throttling is avoided. Differential Revision: https://reviews.llvm.org/D54073 llvm-svn: 346595
2018-11-11 04:05:31 +08:00
; CHECK-NEXT: vmovsd {{.*#+}} xmm0 = mem[0],zero
[NFC][X86][Codegen] Megacommit: mass-regenerate all check lines that were already autogenerated The motivation is that the update script has at least two deviations (`<...>@GOT`/`<...>@PLT`/ and not hiding pointer arithmetics) from what pretty much all the checklines were generated with, and most of the tests are still not updated, so each time one of the non-up-to-date tests is updated to see the effect of the code change, there is a lot of noise. Instead of having to deal with that each time, let's just deal with everything at once. This has been done via: ``` cd llvm-project/llvm/test/CodeGen/X86 grep -rl "; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py" | xargs -L1 <...>/llvm-project/llvm/utils/update_llc_test_checks.py --llc-binary <...>/llvm-project/build/bin/llc ``` Not all tests were regenerated, however.
2021-06-12 04:26:17 +08:00
; CHECK-NEXT: vmovaps %xmm0, out(%rip)
[X86] Regenerate test. NFC. llvm-svn: 281099
2016-09-10 05:36:17 +08:00
; CHECK-NEXT: xorl %eax, %eax
; CHECK-NEXT: retq
[DAGCombine] Fix a bug in a BUILD_VECTOR combine When trying to convert a BUILD_VECTOR into a shuffle, we try to split a single source vector that is twice as wide as the destination vector. We can not do this when we also need the zero vector to create a blend. This fixes PR22774. Differential Revision: http://reviews.llvm.org/D8040 llvm-svn: 231219
2015-03-04 15:27:39 +08:00
entry:
%0 = load <4 x i64>, <4 x i64>* @in, align 32
%vecext = extractelement <4 x i64> %0, i32 0
%vecinit = insertelement <2 x i64> undef, i64 %vecext, i32 0
%vecinit1 = insertelement <2 x i64> %vecinit, i64 0, i32 1
store <2 x i64> %vecinit1, <2 x i64>* @out, align 16
ret i32 0
}