This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Track pointer (mis-)alignment
On Wed, 4 Aug 2010, Diego Novillo wrote:
> On 10-08-04 10:55 , Richard Guenther wrote:
>
> > int
> > get_pointer_alignment (tree exp, unsigned int max_align)
> > {
> > ! if (TREE_CODE (exp) == ADDR_EXPR)
> > ! return get_object_alignment (TREE_OPERAND (exp, 0),
> > ! BITS_PER_UNIT, max_align);
> > ! else if (TREE_CODE (exp) == SSA_NAME
> > ! && POINTER_TYPE_P (TREE_TYPE (exp)))
> > {
> > ! struct ptr_info_def *pi = SSA_NAME_PTR_INFO (exp);
> > ! unsigned align;
> > ! if (!pi)
> > ! return BITS_PER_UNIT;
>
> Why do we give up when there is no pointer info. Shouldn't we resort to the
> previous behaviour?
Well, the previous behavior is optimistic which IMHO isn't quite
a right thing to do. Note that the type on the pointer does mean
even less these days (with mem-ref and pointer conversions being
useless), so this function can't return a conservative correct
default other than BITS_PER_UNIT.
> > *************** duplicate_ssa_name_ptr_info (tree name,
> > *** 276,281 ****
> > --- 285,305 ----
> > }
> >
> >
> > + /* Creates a duplicate of a ssa name NAME defined in statement STMT. */
> > +
> > + tree
> > + duplicate_ssa_name (tree name, gimple stmt)
> > + {
> > + tree new_name = make_ssa_name (SSA_NAME_VAR (name), stmt);
> > + struct ptr_info_def *old_ptr_info = SSA_NAME_PTR_INFO (name);
> > +
> > + if (old_ptr_info)
> > + duplicate_ssa_name_ptr_info (new_name, old_ptr_info);
> > +
> > + return new_name;
>
> Since you're here. Should we assert that STMT has NAME in its LHS?
I think the comment is misleading - stmt is the stmt that is
supoosed to define the new name (thus, SSA_NAME_DEF_STMT (new_name) ==
stmt). I'll adjust it.
> > + }
> > +
> > +
> > /* Release all the SSA_NAMEs created by STMT. */
> >
> > void
> > Index: trunk/gcc/tree-ssa-ccp.c
> > ===================================================================
> > *** trunk.orig/gcc/tree-ssa-ccp.c 2010-08-04 16:24:44.000000000 +0200
> > --- trunk/gcc/tree-ssa-ccp.c 2010-08-04 16:25:04.000000000 +0200
> > *************** static bool
> > *** 840,847 ****
> > --- 840,879 ----
> > ccp_finalize (void)
> > {
> > bool something_changed;
> > + unsigned i;
> >
> > do_dbg_cnt ();
> > +
> > + /* Derive alignment and misalignment information from partially
> > + constant pointers in the lattice. */
> > + for (i = 1; i< num_ssa_names; ++i)
> > + {
> > + tree name = ssa_name (i);
> > + prop_value_t *val;
> > + struct ptr_info_def *pi;
> > + unsigned int tem, align;
> > +
> > + if (!name
> > + || !POINTER_TYPE_P (TREE_TYPE (name)))
> > + continue;
> > +
> > + val = get_value (name);
> > + if (val->lattice_val != CONSTANT
> > + || TREE_CODE (val->value) != INTEGER_CST)
> > + continue;
> > +
> > + /* Trailing constant bits specify the alignment, trailing value
> > + bits the misalignment. */
> > + tem = val->mask.low;
> > + align = (tem& -tem);
> > + if (align == 1)
> > + continue;
> > +
> > + pi = get_ptr_info (name);
> > + pi->align = align;
> > + pi->misalign = TREE_INT_CST_LOW (val->value)& (align - 1);
>
> > + }
> > +
>
> Do we want to repeat this analysis after other propagation passes like DOM,
> VRP, etc?
Well, VRP might have an idea of lower bits, but DOM doesn't. Let's
see how it plays.
Richard.