Sign-extend rather than zero-extend when promoting

the condition for a BRCOND, according to what is
returned by getSetCCResultContents.  Since all
targets return the same thing (ZeroOrOneSetCCResult),
this should be harmless!  The point is that all over
the place the result of SETCC is fed directly into
BRCOND.  On machines for which getSetCCResultContents
returns ZeroOrNegativeOneSetCCResult, this is a
sign-extended boolean.  So it seems dangerous to
also feed BRCOND zero-extended booleans in some
circumstances - for example, when promoting the
condition.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@58861 91177308-0d34-0410-b5e6-96231b3b80d8

1 files changed, 5 insertions, 4 deletions

diff --git a/include/llvm/CodeGen/SelectionDAGNodes.h b/include/llvm/CodeGen/SelectionDAGNodes.h
index 7c78f6ab37..3d5e68fecf 100644
--- a/include/llvm/CodeGen/SelectionDAGNodes.h
+++ b/include/llvm/CodeGen/SelectionDAGNodes.h
@@ -468,10 +468,11 @@ namespace ISD {
     // BR_JT - Jumptable branch. The first operand is the chain, the second
     // is the jumptable index, the last one is the jumptable entry index.
     BR_JT,
-    
-    // BRCOND - Conditional branch.  The first operand is the chain,
-    // the second is the condition, the third is the block to branch
-    // to if the condition is true.
+
+    // BRCOND - Conditional branch.  The first operand is the chain, the
+    // second is the condition, the third is the block to branch to if the
+    // condition is true.  If the type of the condition is not i1, then the
+    // high bits must conform to getSetCCResultContents.
     BRCOND,
 
     // BR_CC - Conditional branch.  The behavior is like that of SELECT_CC, in