[range-ops] patch 05/04: bonus round!

[Aldy Hernandez]

On 7/3/19 7:12 PM, Jeff Law wrote:
> On 7/1/19 4:24 AM, Aldy Hernandez wrote:
>> This is completely unrelated to range-ops itself, but may yield better
>> results in value_range intersections.  It's just something I found while
>> working on VRP, and have been dragging around on our branch.
>>
>> If we know the intersection of two ranges is the empty set, there is no
>> need to conservatively add anything to the result.
>>
>> Tested on x86-64 Linux with --enable-languages=all.
>>
>> Aldy
>>
>> range-ops-intersect-undefined.patch
>>
>> commit 4f9aa7bd1066267eee92f622ff29d78534158e20
>> Author: Aldy Hernandez <aldyh@redhat.com>
>> Date:   Fri Jun 28 11:34:19 2019 +0200
>>
>>      Do not try to further refine a VR_UNDEFINED result when intersecting
>>      value_ranges.
>>
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index 01fb97cedb2..b0d78ee6871 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,3 +1,9 @@
>> +2019-07-01  Aldy Hernandez  <aldyh@redhat.com>
>> +
>> +	* tree-vrp.c (intersect_ranges): If we know the intersection is
>> +	empty, there is no need to conservatively add anything else to
>> +	the set.
> Do we have a test where this improves the code or at least the computed
> ranges?

I have long since lost the testcase, but a little hacking around to dump 
all the cases where we are trying to conservatively refine a 
VR_UNDEFINED, yields tons of hits.  See attached hack.

By far, the most common is the intersection of ~[0,0] and [0,0], which 
yields VR_UNDEFINED.  We then conservatively drop to VR1, which is 
[0,0], basically pessimizing the result.

Other examples include:

unsigned char [38, +INF], unsigned char [22, 22]
unsigned char [4, 4], unsigned char [1, 1]
unsigned char [4, 4], unsigned char [2, 2]
unsigned int [0, 64], unsigned int [128, 128]
unsigned int [0, 6], unsigned int [4294967275, 4294967275]
unsigned int ~[35, 35], unsigned int [35, 35]
unsigned int [46, 52], unsigned int [25, 25]
etc

Within 7 minutes of building a compiler (up to stage2), this incorrect 
refinement of VR_UNDEFINED has been triggered 29000 times.

If we know it's VR_UNDEFINED (the empty set), I think we should leave it 
empty :).

Aldy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hack.patch
Type: text/x-patch
Size: 1563 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20190706/40aa7cd8/attachment.bin>