RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-24 03:33:20 +01:00
Code Issues Projects Releases Wiki Activity
8912979930
llvm-mirror/test/Analysis/BasicAA/2007-08-05-GetOverloadedModRef.ll

17 lines
546 B
LLVM
Raw Normal View History

FileCheck-ize these tests. Harden some of them. llvm-svn: 155432
2012-04-24 11:15:38 +02:00
; RUN: opt < %s -basicaa -gvn -instcombine -S | FileCheck %s
This resolves a regression of BasicAA which failed to find any memory information for overloaded intrinsics (PR1600). This resolves that issue, and improves the matching scheme to use a BitVector rather than a binary search. llvm-svn: 40872
2007-08-06 22:57:16 +02:00
; PR1600
Manually upgrade the test suite to specify the flag to cttz and ctlz. I followed three heuristics for deciding whether to set 'true' or 'false': - Everything target independent got 'true' as that is the expected common output of the GCC builtins. - If the target arch only has one way of implementing this operation, set the flag in the way that exercises the most of codegen. For most architectures this is also the likely path from a GCC builtin, with 'true' being set. It will (eventually) require lowering away that difference, and then lowering to the architecture's operation. - Otherwise, set the flag differently dependending on which target operation should be tested. Let me know if anyone has any issue with this pattern or would like specific tests of another form. This should allow the x86 codegen to just iteratively improve as I teach the backend how to differentiate between the two forms, and everything else should remain exactly the same. llvm-svn: 146370
2011-12-12 12:59:10 +01:00
declare i16 @llvm.cttz.i16(i16, i1)
This resolves a regression of BasicAA which failed to find any memory information for overloaded intrinsics (PR1600). This resolves that issue, and improves the matching scheme to use a BitVector rather than a binary search. llvm-svn: 40872
2007-08-06 22:57:16 +02:00
define i32 @test(i32* %P, i16* %Q) {
FileCheck-ize these tests. Harden some of them. llvm-svn: 155432
2012-04-24 11:15:38 +02:00
; CHECK: ret 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-27 22:17:42 +01:00
%A = load i16, i16* %Q ; <i16> [#uses=1]
%x = load i32, i32* %P ; <i32> [#uses=1]
Manually upgrade the test suite to specify the flag to cttz and ctlz. I followed three heuristics for deciding whether to set 'true' or 'false': - Everything target independent got 'true' as that is the expected common output of the GCC builtins. - If the target arch only has one way of implementing this operation, set the flag in the way that exercises the most of codegen. For most architectures this is also the likely path from a GCC builtin, with 'true' being set. It will (eventually) require lowering away that difference, and then lowering to the architecture's operation. - Otherwise, set the flag differently dependending on which target operation should be tested. Let me know if anyone has any issue with this pattern or would like specific tests of another form. This should allow the x86 codegen to just iteratively improve as I teach the backend how to differentiate between the two forms, and everything else should remain exactly the same. llvm-svn: 146370
2011-12-12 12:59:10 +01:00
%B = call i16 @llvm.cttz.i16( i16 %A, i1 true ) ; <i16> [#uses=1]
[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-27 22:17:42 +01:00
%y = load i32, i32* %P ; <i32> [#uses=1]
This resolves a regression of BasicAA which failed to find any memory information for overloaded intrinsics (PR1600). This resolves that issue, and improves the matching scheme to use a BitVector rather than a binary search. llvm-svn: 40872
2007-08-06 22:57:16 +02:00
store i16 %B, i16* %Q
%z = sub i32 %x, %y ; <i32> [#uses=1]
ret i32 %z
}
Reference in New Issue Copy Permalink