This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Bit CCP and pointer alignment propagation
- From: Richard Guenther <rguenther at suse dot de>
- To: Jay Foad <jay dot foad at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 4 Aug 2010 15:11:50 +0200 (CEST)
- Subject: Re: [PATCH][RFC] Bit CCP and pointer alignment propagation
- References: <AANLkTin2WVSZRfj8rDrBYZKO4nHWe=JFot8XLyw__FUF@mail.gmail.com>
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.