maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/GlobalOpt/2008-04-26-SROA-Global-Alig...

33 lines
1.3 KiB
LLVM
Raw Normal View History

When SRoA'ing a global variable, make sure the new globals get the appropriate alignment. This fixes a miscompilation of 252.eon on x86-64 (rdar://5891920). Bill, please pull this into Tak. llvm-svn: 50308
2008-04-26 15:40:11 +08:00
; Verify that when @G is SROA'd that the new globals have correct
; alignments. Elements 0 and 2 must be 16-byte aligned, and element
; 1 must be at least 8 byte aligned (but could be more).
Convert all tests using TCL-style quoting to use shell-style quoting. This was done through the aid of a terrible Perl creation. I will not paste any of the horrors here. Suffice to say, it require multiple staged rounds of replacements, state carried between, and a few nested-construct-parsing hacks that I'm not proud of. It happens, by luck, to be able to deal with all the TCL-quoting patterns in evidence in the LLVM test suite. If anyone is maintaining large out-of-tree test trees, feel free to poke me and I'll send you the steps I used to convert things, as well as answer any painful questions etc. IRC works best for this type of thing I find. Once converted, switch the LLVM lit config to use ShTests the same as Clang. In addition to being able to delete large amounts of Python code from 'lit', this will also simplify the entire test suite and some of lit's architecture. Finally, the test suite runs 33% faster on Linux now. ;] For my 16-hardware-thread (2x 4-core xeon e5520): 36s -> 24s llvm-svn: 159525
2012-07-02 20:47:22 +08:00
; RUN: opt < %s -globalopt -S | grep "@G.0 = internal unnamed_addr global .*align 16"
; RUN: opt < %s -globalopt -S | grep "@G.1 = internal unnamed_addr global .*align 8"
; RUN: opt < %s -globalopt -S | grep "@G.2 = internal unnamed_addr global .*align 16"
When SRoA'ing a global variable, make sure the new globals get the appropriate alignment. This fixes a miscompilation of 252.eon on x86-64 (rdar://5891920). Bill, please pull this into Tak. llvm-svn: 50308
2008-04-26 15:40:11 +08:00
; rdar://5891920
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:32:32-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin8"
%T = type { double, double, double }
@G = internal global %T zeroinitializer, align 16
define void @test() {
store double 1.0, double* getelementptr (%T* @G, i32 0, i32 0), align 16
store double 2.0, double* getelementptr (%T* @G, i32 0, i32 1), align 8
store double 3.0, double* getelementptr (%T* @G, i32 0, i32 2), align 16
ret void
}
define double @test2() {
[opaque pointer type] Add textual IR support for explicit type parameter to load instruction Essentially the same as the GEP change in r230786. A similar migration script can be used to update test cases, though a few more test case improvements/changes were required this time around: (r229269-r229278) import fileinput import sys import re pat = re.compile(r"((?:=|:|^)\s*load (?:atomic )?(?:volatile )?(.*?))(| addrspace\(\d+\) *)\*($| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$)") for line in sys.stdin: sys.stdout.write(re.sub(pat, r"\1, \2\3*\4", line)) Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7649 llvm-svn: 230794
2015-02-28 05:17:42 +08:00
%V1 = load double, double* getelementptr (%T* @G, i32 0, i32 0), align 16
%V2 = load double, double* getelementptr (%T* @G, i32 0, i32 1), align 8
%V3 = load double, double* getelementptr (%T* @G, i32 0, i32 2), align 16
Split the Add, Sub, and Mul instruction opcodes into separate integer and floating-point opcodes, introducing FAdd, FSub, and FMul. For now, the AsmParser, BitcodeReader, and IRBuilder all preserve backwards compatability, and the Core LLVM APIs preserve backwards compatibility for IR producers. Most front-ends won't need to change immediately. This implements the first step of the plan outlined here: http://nondot.org/sabre/LLVMNotes/IntegerOverflow.txt llvm-svn: 72897
2009-06-05 06:49:04 +08:00
%R = fadd double %V1, %V2
%R2 = fadd double %R, %V3
When SRoA'ing a global variable, make sure the new globals get the appropriate alignment. This fixes a miscompilation of 252.eon on x86-64 (rdar://5891920). Bill, please pull this into Tak. llvm-svn: 50308
2008-04-26 15:40:11 +08:00
ret double %R2
}