On 11/05/13 15:00, Cong Hou wrote:
Can you factor those two hunks of nearly identical code into a single
function and call it twice? I'm also curious if you really need the code to
swap lhs/rhs. When can the LHS of a cond be an integer constant? Don't we
canonicalize it as <ssa_name> <COND> <constant>?
I was not aware that the comparison between a variable and a constant
will always be canonicalized as <ssa_name> <COND> <constant>. Then I
will remove the swap, and as the code is much smaller, I think it may
not be necessary to create a function for them.
Hmm, looking at is_gimple_condexpr, it appears to accept both forms:
/* Return true if T is a GIMPLE condition. */
bool
is_gimple_condexpr (tree t)
{
return (is_gimple_val (t) || (COMPARISON_CLASS_P (t)
&& !tree_could_throw_p (t)
&& is_gimple_val (TREE_OPERAND (t, 0))
&& is_gimple_val (TREE_OPERAND (t, 1))));
}
Sigh. So you probably still need to handle both forms :(
I didn't find this problem from any benchmark, but from another
concern about loop upper bound estimation. Look at the following code:
int foo(unsigned int n, int r)
{
int i;
if (n > 0)
if (n < 4)
{
do {
--n;
r *= 2;
} while (n > 0);
}
return r+n;
}
In order to get the upper bound of the loop in this function, GCC
traverses conditions n<4 and n>0 separately and tries to get any
useful information. But as those two conditions cannot be combined
into one due to this issue (note that n>0 will be transformed into
n!=0), when GCC sees n<4, it will consider the possibility that n may
be equal to 0, in which case the upper bound is UINT_MAX. If those two
conditions can be combined into one, which is n-1<=2, then we can get
the correct upper bound of the loop.
Ah. Ok. Thanks.
jeff
