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/constantfold-initializers.ll

104 lines
3.5 KiB
LLVM
Raw Normal View History

Make ConstantFoldConstantExpression recursively visit the entire ConstantExpr, not just the top-level operator. This allows it to fold many more constants. Also, make GlobalOpt call ConstantFoldConstantExpression on GlobalVariable initializers. llvm-svn: 89659
2009-11-24 00:22:21 +08:00
; RUN: opt < %s -S -globalopt | FileCheck %s
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:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
@.str91250 = global [3 x i8] zeroinitializer
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @A = local_unnamed_addr global i1 false
[opaque pointer type] Add textual IR support for explicit type parameter to gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
2015-03-14 02:20:45 +08:00
@A = global i1 icmp ne (i64 sub nsw (i64 ptrtoint (i8* getelementptr inbounds ([3 x i8], [3 x i8]* @.str91250, i64 0, i64 1) to i64), i64 ptrtoint ([3 x i8]* @.str91250 to i64)), i64 1)
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
; PR11352
@xs = global [2 x i32] zeroinitializer, align 4
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @xs = local_unnamed_addr global [2 x i32] [i32 1, i32 1]
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
Fix a crash on valid (if UB) bitcode that is produced for some global constants in C++11 mode. I have no idea why it required such particular circumstances to get here, the code seems clearly to rely upon unchecked assumptions. Specifically, when we decide to form an index into a struct type, we may have gone through (at least one) zero-length array indexing round, which would have left the offset un-adjusted, and thus not necessarily valid for use when indexing the struct type. This is just an canonicalization step, so the correct thing is to refuse to canonicalize nonsensical GEPs of this form. Implemented, and test case added. Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit him with most of the debugging, and preventing me from writing the wrong code. llvm-svn: 155466
2012-04-25 02:42:47 +08:00
; PR12642
%PR12642.struct = type { i8 }
@PR12642.s = global <{}> zeroinitializer, align 1
[opaque pointer type] Add textual IR support for explicit type parameter to gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
2015-03-14 02:20:45 +08:00
@PR12642.p = constant %PR12642.struct* bitcast (i8* getelementptr (i8, i8* bitcast (<{}>* @PR12642.s to i8*), i64 1) to %PR12642.struct*), align 8
Fix a crash on valid (if UB) bitcode that is produced for some global constants in C++11 mode. I have no idea why it required such particular circumstances to get here, the code seems clearly to rely upon unchecked assumptions. Specifically, when we decide to form an index into a struct type, we may have gone through (at least one) zero-length array indexing round, which would have left the offset un-adjusted, and thus not necessarily valid for use when indexing the struct type. This is just an canonicalization step, so the correct thing is to refuse to canonicalize nonsensical GEPs of this form. Implemented, and test case added. Fixes PR12642. Pair debugged and coded with Richard Smith. =] I credit him with most of the debugging, and preventing me from writing the wrong code. llvm-svn: 155466
2012-04-25 02:42:47 +08:00
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
define internal void @test1() {
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
2015-03-14 02:20:45 +08:00
store i32 1, i32* getelementptr inbounds ([2 x i32], [2 x i32]* @xs, i64 0, i64 0)
%0 = load i32, i32* getelementptr inbounds ([2 x i32], [2 x i32]* @xs, i32 0, i64 0), align 4
store i32 %0, i32* getelementptr inbounds ([2 x i32], [2 x i32]* @xs, i64 0, i64 1)
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
ret void
}
; PR12060
%closure = type { i32 }
@f = internal global %closure zeroinitializer, align 4
@m = global i32 0, align 4
; CHECK-NOT: @f
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @m = local_unnamed_addr global i32 13
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
define internal i32 @test2_helper(%closure* %this, i32 %b) {
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to getelementptr instruction One of several parallel first steps to remove the target type of pointers, replacing them with a single opaque pointer type. This adds an explicit type parameter to the gep instruction so that when the first parameter becomes an opaque pointer type, the type to gep through is still available to the instructions. * This doesn't modify gep operators, only instructions (operators will be handled separately) * Textual IR changes only. Bitcode (including upgrade) and changing the in-memory representation will be in separate changes. * geps of vectors are transformed as: getelementptr <4 x float*> %x, ... ->getelementptr float, <4 x float*> %x, ... Then, once the opaque pointer type is introduced, this will ultimately look like: getelementptr float, <4 x ptr> %x with the unambiguous interpretation that it is a vector of pointers to float. * address spaces remain on the pointer, not the type: getelementptr float addrspace(1)* %x ->getelementptr float, float addrspace(1)* %x Then, eventually: getelementptr float, ptr addrspace(1) %x Importantly, the massive amount of test case churn has been automated by same crappy python code. I had to manually update a few test cases that wouldn't fit the script's model (r228970,r229196,r229197,r229198). The python script just massages stdin and writes the result to stdout, I then wrapped that in a shell script to handle replacing files, then using the usual find+xargs to migrate all the files. update.py: import fileinput import sys import re ibrep = re.compile(r"(^.*?[^%\w]getelementptr inbounds )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") normrep = re.compile( r"(^.*?[^%\w]getelementptr )(((?:<\d* x )?)(.*?)(| addrspace\(\d\)) *\*(|>)(?:$| *(?:%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|\[\[[a-zA-Z]|\{\{).*$))") def conv(match, line): if not match: return line line = match.groups()[0] if len(match.groups()[5]) == 0: line += match.groups()[2] line += match.groups()[3] line += ", " line += match.groups()[1] line += "\n" return line for line in sys.stdin: if line.find("getelementptr ") == line.find("getelementptr inbounds"): if line.find("getelementptr inbounds") != line.find("getelementptr inbounds ("): line = conv(re.match(ibrep, line), line) elif line.find("getelementptr ") != line.find("getelementptr ("): line = conv(re.match(normrep, line), line) sys.stdout.write(line) apply.sh: for name in "$@" do python3 `dirname "$0"`/update.py < "$name" > "$name.tmp" && mv "$name.tmp" "$name" rm -f "$name.tmp" done The actual commands: From llvm/src: find test/ -name *.ll | xargs ./apply.sh From llvm/src/tools/clang: find test/ -name *.mm -o -name *.m -o -name *.cpp -o -name *.c | xargs -I '{}' ../../apply.sh "{}" From llvm/src/tools/polly: find test/ -name *.ll | xargs ./apply.sh After that, check-all (with llvm, clang, clang-tools-extra, lld, compiler-rt, and polly all checked out). The extra 'rm' in the apply.sh script is due to a few files in clang's test suite using interesting unicode stuff that my python script was throwing exceptions on. None of those files needed to be migrated, so it seemed sufficient to ignore those cases. Reviewers: rafael, dexonsmith, grosser Differential Revision: http://reviews.llvm.org/D7636 llvm-svn: 230786
2015-02-28 03:29:02 +08:00
%0 = getelementptr inbounds %closure, %closure* %this, i32 0, i32 0
[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
%1 = load i32, i32* %0, align 4
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
%add = add nsw i32 %1, %b
ret i32 %add
}
define internal void @test2() {
entry:
[opaque pointer type] Add textual IR support for explicit type parameter to gep operator Similar to gep (r230786) and load (r230794) changes. Similar migration script can be used to update test cases, which successfully migrated all of LLVM and Polly, but about 4 test cases needed manually changes in Clang. (this script will read the contents of stdin and massage it into stdout - wrap it in the 'apply.sh' script shown in previous commits + xargs to apply it over a large set of test cases) import fileinput import sys import re rep = re.compile(r"(getelementptr(?:\s+inbounds)?\s*\()((<\d*\s+x\s+)?([^@]*?)(|\s*addrspace\(\d+\))\s*\*(?(3)>)\s*)(?=$|%|@|null|undef|blockaddress|getelementptr|addrspacecast|bitcast|inttoptr|zeroinitializer|<|\[\[[a-zA-Z]|\{\{)", re.MULTILINE | re.DOTALL) def conv(match): line = match.group(1) line += match.group(4) line += ", " line += match.group(2) return line line = sys.stdin.read() off = 0 for match in re.finditer(rep, line): sys.stdout.write(line[off:match.start()]) sys.stdout.write(conv(match)) off = match.end() sys.stdout.write(line[off:]) llvm-svn: 232184
2015-03-14 02:20:45 +08:00
store i32 4, i32* getelementptr inbounds (%closure, %closure* @f, i32 0, i32 0)
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
%call = call i32 @test2_helper(%closure* @f, i32 9)
store i32 %call, i32* @m, align 4
ret void
}
GlobalOpt: Don't optimize dllimport for initializers Referencing a dllimport variable requires actually instructions, not just a relocation. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4249 llvm-svn: 211571
2014-06-24 14:53:45 +08:00
; PR19955
@dllimportptr = global i32* null, align 4
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @dllimportptr = local_unnamed_addr global i32* null, align 4
GlobalOpt: Don't optimize dllimport for initializers Referencing a dllimport variable requires actually instructions, not just a relocation. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4249 llvm-svn: 211571
2014-06-24 14:53:45 +08:00
@dllimportvar = external dllimport global i32
define internal void @test3() {
entry:
store i32* @dllimportvar, i32** @dllimportptr, align 4
ret void
}
@dllexportptr = global i32* null, align 4
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @dllexportptr = local_unnamed_addr global i32* @dllexportvar, align 4
GlobalOpt: Don't optimize dllimport for initializers Referencing a dllimport variable requires actually instructions, not just a relocation. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4249 llvm-svn: 211571
2014-06-24 14:53:45 +08:00
@dllexportvar = dllexport global i32 0, align 4
; CHECK: @dllexportvar = dllexport global i32 20, align 4
define internal void @test4() {
entry:
store i32 20, i32* @dllexportvar, align 4
store i32* @dllexportvar, i32** @dllexportptr, align 4
ret void
}
GlobalOpt: Don't optimize thread_local for initializers Folding a reference to a thread_local variable into another global variable's initializer is very problematic, there is no relocation that exists to represent such an access. llvm-svn: 211762
2014-06-26 11:02:19 +08:00
@threadlocalptr = global i32* null, align 4
; CHECK: @threadlocalptr = global i32* null, align 4
@threadlocalvar = external thread_local global i32
define internal void @test5() {
entry:
store i32* @threadlocalvar, i32** @threadlocalptr, align 4
ret void
}
GlobalOpt: Optimize in the face of insertvalue/extractvalue GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
2014-08-08 13:50:43 +08:00
@test6_v1 = internal global { i32, i32 } { i32 42, i32 0 }, align 8
@test6_v2 = global i32 0, align 4
IR: Introduce local_unnamed_addr attribute. If a local_unnamed_addr attribute is attached to a global, the address is known to be insignificant within the module. It is distinct from the existing unnamed_addr attribute in that it only describes a local property of the module rather than a global property of the symbol. This attribute is intended to be used by the code generator and LTO to allow the linker to decide whether the global needs to be in the symbol table. It is possible to exclude a global from the symbol table if three things are true: - This attribute is present on every instance of the global (which means that the normal rule that the global must have a unique address can be broken without being observable by the program by performing comparisons against the global's address) - The global has linkonce_odr linkage (which means that each linkage unit must have its own copy of the global if it requires one, and the copy in each linkage unit must be the same) - It is a constant or a function (which means that the program cannot observe that the unique-address rule has been broken by writing to the global) Although this attribute could in principle be computed from the module contents, LTO clients (i.e. linkers) will normally need to be able to compute this property as part of symbol resolution, and it would be inefficient to materialize every module just to compute it. See: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160509/356401.html http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20160516/356738.html for earlier discussion. Part of the fix for PR27553. Differential Revision: http://reviews.llvm.org/D20348 llvm-svn: 272709
2016-06-15 05:01:22 +08:00
; CHECK: @test6_v2 = local_unnamed_addr global i32 42, align 4
GlobalOpt: Optimize in the face of insertvalue/extractvalue GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
2014-08-08 13:50:43 +08:00
define internal void @test6() {
[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
%load = load { i32, i32 }, { i32, i32 }* @test6_v1, align 8
GlobalOpt: Optimize in the face of insertvalue/extractvalue GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
2014-08-08 13:50:43 +08:00
%xv0 = extractvalue { i32, i32 } %load, 0
%iv = insertvalue { i32, i32 } %load, i32 %xv0, 1
%xv1 = extractvalue { i32, i32 } %iv, 1
store i32 %xv1, i32* @test6_v2, align 4
ret void
}
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
@llvm.global_ctors = appending constant
GlobalOpt: Optimize in the face of insertvalue/extractvalue GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
2014-08-08 13:50:43 +08:00
[6 x { i32, void ()* }]
Use the target-aware constant folder on expressions to improve the chance they'll be simple enough to simulate, and to reduce the chance we'll encounter equal but different simple pointer constants. This removes the symptoms from PR11352 but is not a full fix. A proper fix would either require a guarantee that two constant objects we simulate are folded when equal, or a different way of handling equal pointers (ie., trying a constantexpr icmp on them to see whether we know they're equal or non-equal or unsure). llvm-svn: 151093
2012-02-22 06:08:06 +08:00
[{ i32, void ()* } { i32 65535, void ()* @test1 },
GlobalOpt: Don't optimize dllimport for initializers Referencing a dllimport variable requires actually instructions, not just a relocation. This fixes PR19955. Differential Revision: http://reviews.llvm.org/D4249 llvm-svn: 211571
2014-06-24 14:53:45 +08:00
{ i32, void ()* } { i32 65535, void ()* @test2 },
{ i32, void ()* } { i32 65535, void ()* @test3 },
GlobalOpt: Don't optimize thread_local for initializers Folding a reference to a thread_local variable into another global variable's initializer is very problematic, there is no relocation that exists to represent such an access. llvm-svn: 211762
2014-06-26 11:02:19 +08:00
{ i32, void ()* } { i32 65535, void ()* @test4 },
GlobalOpt: Optimize in the face of insertvalue/extractvalue GlobalOpt didn't know how to simulate InsertValueInst or ExtractValueInst. Optimizing these is pretty straightforward. N.B. This came up when looking at clang's IRGen for MS ABI member pointers; they are represented as aggregates. llvm-svn: 215184
2014-08-08 13:50:43 +08:00
{ i32, void ()* } { i32 65535, void ()* @test5 },
{ i32, void ()* } { i32 65535, void ()* @test6 }]