VRP: range info of new variables

[Marc Glisse]

On Mon, 16 May 2016, Jeff Law wrote:

>> - Now that I think of it, maybe I should check that the variable is not
>> a pointer before calling set_range_info? Having range [0, 1] makes it
>> unlikely, but who knows...
> Maybe using an assert would be better.

I don't think having a pointer there would be completely wrong, just 
unlikely, so I'd rather add a check but not assert.

>> Index: gcc/tree-vrp.c
>> ===================================================================
>> --- gcc/tree-vrp.c	(revision 236194)
>> +++ gcc/tree-vrp.c	(working copy)
>> @@ -8933,20 +8933,24 @@ simplify_truth_ops_using_ranges (gimple_
>>      gimple_assign_set_rhs_with_ops (gsi,
>>  				    need_conversion
>>  				    ? NOP_EXPR : TREE_CODE (op0), op0);
>>    /* For A != B we substitute A ^ B.  Either with conversion.  */
>>    else if (need_conversion)
>>      {
>>        tree tem = make_ssa_name (TREE_TYPE (op0));
>>        gassign *newop
>>  	= gimple_build_assign (tem, BIT_XOR_EXPR, op0, op1);
>>        gsi_insert_before (gsi, newop, GSI_SAME_STMT);
>> +      if (TYPE_PRECISION (TREE_TYPE (tem)) > 1)
>> +	set_range_info (tem, VR_RANGE,
>> +			wi::zero (TYPE_PRECISION (TREE_TYPE (tem))),
>> +			wi::one (TYPE_PRECISION (TREE_TYPE (tem))));
> Is there actually a case where TYPE_PRECISION (TREE_TYPE (tem)) > 1 is ever 
> false?  Would an assert make more sense here?

op0 can have precision 1, so tem can as well. In most cases I would expect 
need_conversion to be false in that case though. However, it doesn't seem 
impossible to have several types with 1-bit precision that are not 
equivalent (different TYPE_SIGN for instance). So again, I don't feel 
comfortable adding an assert. But I am open to proofs that those events 
cannot happen.

>>  static bool
>>  simplify_conversion_using_ranges (gimple *stmt)
> Your ChangeLog mentions simplify_switch_using_ranges, not 
> simplify_conversion_using_ranges.

Oups, bad copy-paste (I keep too much context in the diff for diff -p to 
give useful results), thanks.

> This is OK for the trunk -- your call on asserting the variable is not a 
> pointer before calling set_range_info.  Similarly on the check that the 
> TYPE_PRECISION (TREE_TYPE (tem)) > 1.

-- 
Marc Glisse