Re: [patch] Vectorizer: resolve mix of pointer and object

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> On Thu, Jan 13, 2005 at 11:12:20AM +0200, Ira Rosen wrote:
> > !   if (TREE_CODE (TREE_TYPE (expr)) == POINTER_TYPE)
> ...
> > !    case ADDR_EXPR:
> > !      oprnd0 = TREE_OPERAND (expr, 0);
> > !      next_ref = oprnd0;
> > !      break;
>
> Continuing a pointer recursion through an "&"?  That doesn't
> seem right at all.
>

yes, here objects an pointers are still intertwined.

There are actually two places where we are mixing pointers and objects.
This patch partially addresses one of them:

(1) The data we store in VECT_DR_BASE and in DR_BASE is sometimes an
address and sometimes an object. The first of the two should always be a
pointer, and this is indeed fixed by this patch (while also renaming the
macro to VECT_DR_BASE_ADDRESS). The second should always be an object, and
this was not addressed by this patch (didn't notice it before). We'll send
these bits separately from the rest:

(2) The other place where objects and pointers as mixed is within the
analysis that tries to extract the base, offset, alignment and memtag of a
data-ref (this is where the code fragment you pointed out above is from).
In this analysis we always start off with an object
(array-ref/indirect-ref) and from there on we try to get the information we
need by peeling off operators recursively, and along the way we end up
switching between objects and pointers throughout the analysis. Indeed this
patch does not try to clean away this mixture, just make it slightly
clearer where we deal with objects and where with pointers. I think this
could be fixed too. We will always have to switch between objects and
addresses, but we probably could break the code into separate functions,
and call one from the other when we need to (for example, we may start with
an indirect-ref '*ptr' (an object) where 'ptr=q+&a[16]'; during the
recursion we get '&a[16]' (a pointer) and want to analyze it, calling
get_inner_reference on 'a[16]' (an object)). To be continued,


dorit

>
> r~