[PATCH] Handling == or != comparisons that may affect range test optimization.
Jeff Law
law@redhat.com
Tue Nov 5 22:39:00 GMT 2013
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
More information about the Gcc-patches
mailing list