On 05/16/2012 12:48 PM, Andrew Pinski wrote:
+ /* Handle 0/1 specially because boolean types and precision of one types,
+ will cause the diff to always be 1. Note this really should have
+ simplified before reaching here. */
+ /* A ? 1 : 0 is just (type)(A!=0). */
+ if (integer_zerop (treeop2)&& integer_onep (treeop1))
+ {
+ tree t = fold_convert (TREE_TYPE (treeop0), integer_zero_node);
+ tree tmp = fold_build2 (NE_EXPR, TREE_TYPE (treeop0), treeop0, t);
+ tmp = fold_convert (type, tmp);
+ return expand_normal (tmp);
+ }
+
+ /* A ? 0 : 1 is just (type)(A==0). */
+ if (integer_zerop (treeop1)&& integer_onep (treeop0))
+ {
+ tree t = fold_convert (TREE_TYPE (treeop0), integer_zero_node);
+ tree tmp = fold_build2 (EQ_EXPR, TREE_TYPE (treeop0), treeop0, t);
+ tmp = fold_convert (type, tmp);
+ return expand_normal (tmp);
+ }
Well, why *don't* you handle them before here? I completely agree that
they seem out of place in an _addcc function.
+ /* A ? CST1 : CST2 can be expanded as CST2 + (!A)*(CST1 - CST2) */
+ if (TREE_CODE (treeop1) == INTEGER_CST
+&& TREE_CODE (treeop2) == INTEGER_CST)
+ diff = int_const_binop (MINUS_EXPR, treeop1, treeop2);
Here you're bypassing the large amount of logic we've got in
e.g. ix86_expand_int_movcc for handling exactly this case, and
in more clever ways than you're doing here.
Please continue to defer to cmov for this.
+ /* A ? b : b+c can be expanded as b + (!A)*(c) */
+ /* A ? b + c : b can be expanded as b + (!A)*(c) */
What has MULT got to do with it? I think these comments are just confusing.
r~
