Re: [PATCH][RFC] Bit CCP and pointer alignment propagation

[Richard Guenther <rguenther at suse dot de>]

On Wed, 4 Aug 2010, Jay Foad wrote:

> > > > + typedef struct bit_prop_value_d {
> > > > +   /* Lattice value.  */
> > > > +   unsigned lattice_val;
> > > > +
> > > > +   /* Bit lattice value.  Zero for constant, one for varying.  */
> > > > +   double_int bit_lattice_val;
> > >
> > > I always think of this member as a mask, why not call it so?  At runtime
> > > for a value X that has MASK and VALUE in the lattice this holds:
> > > (X & ~MASK) == VALUE .  Actually I'm not sure you ensure this as you
> > > sometimes only adjust the mask, but not value, so you we might know only
> > > this: (X & ~MASK) == (VALUE & ~MASK).
> >
> > That's true, varying value bits have undefined content.
> 
> If you define a canonical form where varying value bits have to be zero:
> 
>   gcc_assert((foo.value & foo.bit_lattice_val) == 0);
> 
> then you can use non-canonical values in the (bit_lattice_val, value)
> pair to represent different lattice values. For example:
> 
> lattice_val   : represented by (bit_lattice_val, value)
> -------------------------------------------------------
> UNINITIALIZED : (-1, -2)
> UNDEFINED     : (-1, -1)
> CONSTANT      : any (blv, v) where v & blv == 0
> VARYING       : (-1, 1)
> 
> With this scheme (v & blv) + 2 gives you the lattice value as you have
> it now.  Then you don't need the lattice_val field in struct
> bit_prop_value_d, which should make them pack together much better.
> Dunno whether it's worth the obfuscation, though.

IMHO it's not.  You also would loose the convenient trick to
be able to sign-/zero-extend the mask to treat unknown sign-bits
correctly.

Richard.