RPCS3/llvm
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm.git synced 2025-01-13 07:50:50 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity
llvm/test/Transforms/SCCP/2008-05-23-UndefCallFold.ll

15 lines
377 B
LLVM
Raw Normal View History

Fix the remaining TCL-style quotes found in the testsuite. This is another mechanical change accomplished though the power of terrible Perl scripts. I have manually switched some "s to 's to make escaping simpler. While I started this to fix tests that aren't run in all configurations, the massive number of tests is due to a really frustrating fragility of our testing infrastructure: things like 'grep -v', 'not grep', and 'expected failures' can mask broken tests all too easily. Essentially, I'm deeply disturbed that I can change the testsuite so radically without causing any change in results for most platforms. =/ git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159547 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-02 19:09:46 +00:00
; RUN: opt < %s -sccp -S | not grep "ret i32 undef"
Fix PR2358 by resolving calls with undef arguments to overdefined. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51535 91177308-0d34-0410-b5e6-96231b3b80d8
2008-05-24 03:59:33 +00:00
; PR2358
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
target triple = "i686-pc-linux-gnu"
define i32 @x(i32 %b) {
entry:
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-12 11:59:10 +00:00
%val = call i32 @llvm.cttz.i32(i32 undef, i1 true)
Fix PR2358 by resolving calls with undef arguments to overdefined. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51535 91177308-0d34-0410-b5e6-96231b3b80d8
2008-05-24 03:59:33 +00:00
ret i32 %val
}
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146370 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-12 11:59:10 +00:00
declare i32 @llvm.cttz.i32(i32, i1)
Fix PR2358 by resolving calls with undef arguments to overdefined. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@51535 91177308-0d34-0410-b5e6-96231b3b80d8
2008-05-24 03:59:33 +00:00
Reference in New Issue Copy Permalink