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/PowerPC/unal-vec-negarith.ll

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

18 lines
552 B
LLVM
Raw Normal View History

Adding -verify-machineinstrs option to PowerPC tests Currently we have a number of tests that fail with -verify-machineinstrs. To detect this cases earlier we add the option to the testcases with the exception of tests that will currently fail with this option. PR 27456 keeps track of this failures. No code review, as discussed with Hal Finkel. llvm-svn: 277624
2016-08-04 02:17:35 +08:00
; RUN: llc -verify-machineinstrs -debug-only=isel <%s >%t 2>&1 && FileCheck <%t %s
[PowerPC] Compute the MMO offset for an unaligned load with signed arithmetic If you compute the MMO offset using unsigned arithmetic, you end up with a large positive offset instead of a small negative one. In theory, this could cause bad instruction-scheduling decisions later. I noticed this by inspection from the debug output, and using that for the regression test is the best I can do right now. llvm-svn: 246805
2015-09-04 05:12:15 +08:00
; REQUIRES: asserts
target datalayout = "E-m:e-i64:64-n32:64"
target triple = "powerpc64-unknown-linux-gnu"
define <16 x i8> @test_l_v16i8(<16 x i8>* %p) #0 {
entry:
%r = load <16 x i8>, <16 x i8>* %p, align 1
ret <16 x i8> %r
[CodeGen] Use MIR syntax for MachineMemOperand printing Get rid of the "; mem:" suffix and use the one we use in MIR: ":: (load 2)". rdar://38163529 Differential Revision: https://reviews.llvm.org/D42377 llvm-svn: 327580
2018-03-15 05:52:13 +08:00
; CHECK-NOT: v4i32,ch = llvm.ppc.altivec.lvx{{.*}}<(load 31 from %ir.p + 4294967281, align 1)>
; CHECK: v4i32,ch = llvm.ppc.altivec.lvx{{.*}}<(load 31 from %ir.p - 15, align 1)>
[PowerPC] Compute the MMO offset for an unaligned load with signed arithmetic If you compute the MMO offset using unsigned arithmetic, you end up with a large positive offset instead of a small negative one. In theory, this could cause bad instruction-scheduling decisions later. I noticed this by inspection from the debug output, and using that for the regression test is the best I can do right now. llvm-svn: 246805
2015-09-04 05:12:15 +08:00
}
attributes #0 = { nounwind "target-cpu"="pwr7" }