[PATCH][mem-ref] Re-enable IVOPTs, build MEM_REF instead of TARGET_MEM_REF (help!)

[Zdenek Dvorak]

Hi,

> > The tree-affine.c changes are a bit dubious; given affine combination i
> > + p + j, where i and j are of sizetype and p is of type char *,  it will
> > produce (char *) i pointer_plus (sizetype) p pointer_plus j, instead of
> > p pointer_plus (i+j) or (p pointer_plus i) pointer_plus j.  Expression
> > simplification may (or may not -- I did not check) fix these casts, but it
> > would be better for aff_combination_to_tree just produced the correct
> > expression instead.  A simple way to do that is to
> > initialize expr in aff_combination_to_tree to a pointer-type element of
> > the affine combination (and exclude this element from the
> > add_elt_to_tree loop, of course).
> 
> folding indeed does re-order operands to build POINTER_PLUS_EXPR if
> you pass it i + (sizetype)p.
>
> I went over the changes in tree-affine.c
> again and I find them straight-forward (even though I admit that with
> this if (POINTER_TYPE_P (type)) fold_build2 (POINTER_PLUS_EXPR, ...
> else fold_build2 (PLUS_EXPR, ... appearing in more places a generic
> helper for this would look less ugly.  I wouldn't mind extending
> size_binop / size_unop to handle this).
> 
> With doing the pointer separation upfront I'm not sure what invariants
> we can rely on in the affine combination -- will there be at most
> one pointer?

Not in general.  If pointers are cast to integers in the original
program, the affine combination may contain several elements of the
pointer type (the casts are stripped if they do not change
TYPE_PRECISION).  Perhaps more common is the case that the affine
combination holds a result of pointer difference, say p + (q-r).

Thinking about it, getting any sane behavior in aff_combination_to_tree
in these cases is a bit difficult, so I guess it is OK to commit the
patch as it is now.

> What about comb->rest?

The type of comb->rest is comb->type if !POINTER_TYPE_P (comb->type),
and sizetype otherwise,

Zdenek