diff options
author | Bob Wilson <bob.wilson@apple.com> | 2009-01-22 22:05:48 +0000 |
---|---|---|
committer | Bob Wilson <bob.wilson@apple.com> | 2009-01-22 22:05:48 +0000 |
commit | c2dc7ee5d0782b63e3b5dc7da115200e2fe30f78 (patch) | |
tree | a1a6bd479e014c91e4a2b6bbed31c160a5c52c82 /clang/lib/CodeGen/CodeGenModule.cpp | |
parent | 1f3411de47805b1cd44b4734b19e032cbdc2b8c7 (diff) | |
download | bcm5719-llvm-c2dc7ee5d0782b63e3b5dc7da115200e2fe30f78.tar.gz bcm5719-llvm-c2dc7ee5d0782b63e3b5dc7da115200e2fe30f78.zip |
Fix a minor bug in DAGCombiner's folding of SELECT. Folding "select C, 0, 1"
to "C ^ 1" is only valid when C is known to be either 0 or 1. Most of the
similar foldings in this function only handle "i1" types, but this one appears
intentionally written to handle larger integer types. If C has an integer
type larger than "i1", this needs to check if the high bits of a boolean
are known to be zero. I also changed the comment to describe this folding as
"C ^ 1" instead of "~C", since that is what the code does and since the latter
would only be valid for "i1" types. The good news is that most LLVM targets
use TargetLowering::ZeroOrOneBooleanContent so this change will not disable
the optimization; the bad news is that I've been unable to come up with a
testcase to demonstrate the problem.
I have also removed a "FIXME" comment for folding "select C, X, 0" to "C & X",
since the code looks correct to me. It could be made more aggressive by not
limiting the type to "i1", but that would then require checking for
TargetLowering::ZeroOrNegativeOneBooleanContent. Similar changes could be
done for the other SELECT foldings, but it was decided to be not worth the
trouble and complexity (see e.g., r44663).
llvm-svn: 62790
Diffstat (limited to 'clang/lib/CodeGen/CodeGenModule.cpp')
0 files changed, 0 insertions, 0 deletions