This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Hi,

On Fri, 30 Jul 2010, Richard Guenther wrote:

> > > + bit_prop_value_convert (tree type, bit_prop_value_t rval, tree rval_type)
> > > + {
> > > +   bit_prop_value_t val;
> > > +   bool uns;
> > > + 
> > > +   /* First extend lattice and value according to the original type.  */
> > > +   uns = (TREE_CODE (rval_type) == INTEGER_TYPE && TYPE_IS_SIZETYPE (rval_type)
> > > + 	 ? 0 : TYPE_UNSIGNED (rval_type));
> > > +   val.bit_lattice_val = double_int_ext (rval.bit_lattice_val,
> > > + 					TYPE_PRECISION (rval_type), uns);
> > 
> > ... but here you extend until the width of double_int.  Perhaps you want 
> > to mask out the upper bits again?
> > (And a lattice can't be sign/zero-extended :)  A mask could be.)
> 
> Well - if the value is signed and we do not know its sign bit then
> we have to sign extend the lattice.

You can't extend a lattice, because a lattice is a set of elements with 
some properties.  I was refering to the comment "/* First extend lattice 
...".

But yes, I didn't notice that your use of TYPE_PRECISION in generating the 
initial mask was only in the context of pointer types, hence unsigned.

> > Here you test the high bit of the mask, but above you fill the mask 
> > only upto TYPE_PRECISION.  I'm not sure if it matters for correctness, 
> > though.
> 
> Where exactly?  The lattice should always be extended as to how the
> value is extended.

Yeah, see above, I was confused.


Ciao,
Michael.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]