Hi,
On Tue, 9 Aug 2011, Richard Guenther wrote:
> > Actually we should adjust the ranges only if it's either all positive
> > or negative values from the start and the adjustment keeps us on the
> > same side of zero.
>
> So we kept discussing this to death somewhat. Which eventually resulted
On 9 August 2011 13:23, Richard Guenther wrote:
> 2011-08-08 Richard Guenther
>
> * tree-vrp.c (zero_nonzero_bits_from_vr): Also return precise
> information for with only negative values.
"for *ranges* with" ?
Jay.
On Mon, 8 Aug 2011, Richard Guenther wrote:
> On Mon, 8 Aug 2011, Richard Guenther wrote:
>
> > On Fri, 5 Aug 2011, Paolo Bonzini wrote:
> >
> > > On 08/05/2011 01:04 PM, Richard Guenther wrote:
> > > > (I believe that's the only bit we know sth about
> > > > when both vr.min and vr.max are nega
On Mon, 8 Aug 2011, Richard Guenther wrote:
> On Fri, 5 Aug 2011, Paolo Bonzini wrote:
>
> > On 08/05/2011 01:04 PM, Richard Guenther wrote:
> > > (I believe that's the only bit we know sth about
> > > when both vr.min and vr.max are negative).
> >
> > Depends, if the value is between -2^16 and
On Fri, 5 Aug 2011, Paolo Bonzini wrote:
> On 08/05/2011 01:04 PM, Richard Guenther wrote:
> > (I believe that's the only bit we know sth about
> > when both vr.min and vr.max are negative).
>
> Depends, if the value is between -2^16 and -1, we know something about all the
> bits to the left of b
On 08/05/2011 01:04 PM, Richard Guenther wrote:
(I believe that's the only bit we know sth about
when both vr.min and vr.max are negative).
Depends, if the value is between -2^16 and -1, we know something about
all the bits to the left of bit 15. I think a better mask is:
* MUST_BE_NONZERO
This removes one weakness in BIT_IOR_EXPR handling which gives
up even if we can compute a fully negative range. The following
thus extends zero_nonzero_bits_from_vr to extract sign-bit
information (I believe that's the only bit we know sth about
when both vr.min and vr.max are negative). It als
