diff options
| author | Hal Finkel <hfinkel@anl.gov> | 2015-09-03 21:12:15 +0000 |
|---|---|---|
| committer | Hal Finkel <hfinkel@anl.gov> | 2015-09-03 21:12:15 +0000 |
| commit | c2a163944ae333419b032f04e77d93527308b46a (patch) | |
| tree | 9c1919ef3d6cd29cb53caecbba39e43e7070d4ca /test/CodeGen/PowerPC/unal-vec-negarith.ll | |
| parent | 5707dff00a39390c595f7e144ed13b331242bafd (diff) | |
[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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@246805 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'test/CodeGen/PowerPC/unal-vec-negarith.ll')
| -rw-r--r-- | test/CodeGen/PowerPC/unal-vec-negarith.ll | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/test/CodeGen/PowerPC/unal-vec-negarith.ll b/test/CodeGen/PowerPC/unal-vec-negarith.ll new file mode 100644 index 00000000000..faac891f5c6 --- /dev/null +++ b/test/CodeGen/PowerPC/unal-vec-negarith.ll @@ -0,0 +1,17 @@ +; RUN: llc -debug-only=isel <%s >%t 2>&1 && FileCheck <%t %s +; 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 + +; CHECK-NOT: v4i32,ch = llvm.ppc.altivec.lvx{{.*}}<LD31[%p+4294967281](align=1)> +; CHECK: v4i32,ch = llvm.ppc.altivec.lvx{{.*}}<LD31[%p+-15](align=1)> +} + +attributes #0 = { nounwind "target-cpu"="pwr7" } + |