[PATCH] mem-ref2 merge, core patch

[Jan Hubicka]

> On Mon, 28 Jun 2010, Paolo Bonzini wrote:
> 
> > On 06/28/2010 12:58 PM, Richard Guenther wrote:
> > > INDIRECT_REF is not allowed in gimple.  You can have bare decls or
> > > MEM_REF, and both can be wrapped inside a handled_component_p chain.
> > > (There also still exist ALIGN_INDIRECT_REF and MISALIGNED_INDIRECT_REF
> > > created by the vectorizer - I will do followup patches to remove those
> > > as well)
> > > 
> > > Basically MEM_REF can appear wherever an INDIRECT_REF or a decl could
> > > previously apper.
> > 
> > Thanks, this should likely go in the docs.
> 
> I'm going to search for a proper place ...
> 
> > > > Would it make sense to change the other INDIRECT_REF_P types into flags on
> > > > MEM_REF?
> > > 
> > > INDIRECT_REF_P will be no longer necessary on gimple after I fixed
> > > up the vectorizer to not use ALIGN_INDIRECT_REF and
> > > MISALIGNED_INDIRECT_REF.  Where it currently appears it is solely
> > > because of those two (I didn't bother to change it to
> > > tests for ALIGN_INDIRECT_REF and MISALIGNED_INDIRECT_REF excluding
> > > INDIRECT_REF).
> > 
> > Then I had understood correctly, thanks. :)  Any idea about the future
> > representation of ALIGN_INDIRECT_REF and MISALIGNED_INDIRECT_REF?
> 
> ALIGN_INDIRECT_REF I will replace with
> 
>   ptr = ptr & mask;
>   MEM_REF [ptr];
> 
> thus simply do what expansion replaces it with.  That will allow
> straight-forward tracking of alignment via ...
> 
> ... the replacement for MISALIGNED_INDIRECT_REF.  We have the
> long-standing problem of not being able to track alignment
> or conservatively assess that of pointers.  My plan is to
> embed alignment information in SSA_NAME_PTR_INFO, an
> alignment value plus a misalignment value.  Thus,
> 
> double x;
> 
> char *foo(void)
> {
>   char *p = &x;  alignment 8, misalign 0
>   p++;  alignment 8, misalign 1
>   p++;  alignment 8, misalign 2
>   ...
> }

This is definitly important for stringop expansion, especially when we can
track the alignment returned from malloc to be a lot greater than what
type suggest...

Honza