llvm-project/llvm/test/Transforms/ConstProp/2007-11-23-cttz.ll

; RUN: opt < %s -constprop -S | grep {ret i13 13}
; PR1816
declare i13 @llvm.cttz.i13(i13, i1)

define i13 @test() {
	%X = call i13 @llvm.cttz.i13(i13 0, i1 true)
	ret i13 %X
}
Change tests from "opt %s" to "opt < %s" so that opt doesn't see the input filename so that opt doesn't print the input filename in the output so that grep lines in the tests don't unintentionally match strings in the input filename. llvm-svn: 81537 2009-09-12 02:01:28 +08:00			`; RUN: opt < %s -constprop -S \| grep {ret i13 13}`
Fix PR1816, by correcting the broken definition of APInt::countTrailingZeros. llvm-svn: 44296 2007-11-24 06:42:31 +08:00			`; PR1816`
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 19:59:10 +08:00			`declare i13 @llvm.cttz.i13(i13, i1)`
Fix PR1816, by correcting the broken definition of APInt::countTrailingZeros. llvm-svn: 44296 2007-11-24 06:42:31 +08:00
			`define i13 @test() {`
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 19:59:10 +08:00			`%X = call i13 @llvm.cttz.i13(i13 0, i1 true)`
Fix PR1816, by correcting the broken definition of APInt::countTrailingZeros. llvm-svn: 44296 2007-11-24 06:42:31 +08:00			`ret i13 %X`
			`}`