higher_equal and the widen bits

[Tom Rodriguez]

> So since higher_equal is cmp(meet(t), t), if t, which is TypeInt::POS, had WidenMax then, this->meet(t) would also have WidenMax so it would work as expected for any widen bits.  I notice that the widest integer types TypeInt::INT and TypeLong::LONG are initialized with WidenMax.
> 
>  TypeInt::INT     = TypeInt::make(min_jint,max_jint, WidenMax); // 32-bit integers
>  TypeLong::LONG    = TypeLong::make(min_jlong,max_jlong,WidenMax); // 64-bit integers
> 
> Presumably this is because they are already as wide as they can get.  Making POS, POS1 and SYMINT WidenMax seems ok since more detailed widening of those types isn't that interesting.
> 
> It still bugs me that higher_equal considers the widen bits.  Some of our tests are against singletons so there's no problem there but many of the tests are against computed types.  I'm going to add a little logic to higher_equal to see if it fails very often for types which differ only by the widen bits.

It seems fairly rare in real programs, though there's a systematic failure in some superword code where we're looking at the values being stored and see ((i << 24) >> 24) with the type int:-128..127:www which fails the higher_equal(TypeInt::BYTE) test because of the widen bits.  I think I'm going to leave this alone.

tom

> 
> tom
> 
>> 
>> (FTR, the purpose of the widen bits is to detect data flow loops in CCP which tend to create slowly sequences of slowly widening type values of the form [0..1], [0..2], [0..3], ..., [0..maxint], [minint..maxint].  This is typical with loop iteration variables, as the dataflow solver works around the loop.  The intermediate steps are probably not interesting, and the widen bits help us decide to skip most of the steps after the first few.  See TypeInt::widen.)
>> 
>> -- John
>