[patch] Externalize data-ref analysis - part 1

Ira Rosen IRAR@il.ibm.com
Tue Jul 19 09:41:00 GMT 2005






Daniel Berlin <dberlin@dberlin.org> wrote on 06/07/2005 18:33:43:
>
> 1. Correct me if i'm wrong, but it looks like some fields are valid on
> array references but not pointer references, and vice versa.
>
> If this is true, we should probably add an enum to tell what kind of
> reference something is (pointer or array), instead of checking whether
> certain fields are null, etc.  This would also enable us to make sure
> nobody is trying to use fields on pointer references or array references
> that are not valid.
>
> 2. You added an alignment parameter to find_data_references_in_loop and
> downward, but it's not documented in find_data_references_in_loop.
>
> It's also very unclear what it is.
> The only docs in the lower functions is "The required alignment in
> bytes".
> Required for what, exactly?
>
> If this is information about what the vectorizer requires in terms of
> alignment for a given loop, that should not be passed to this generic
> function. *That* part (and whatever misalignment info it needs) should
> be computed separately by the vectorizer.
>

Here is a patch (part 1 and 2) that addresses the above comments (and also
this one http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00356.html).

Alignment is no longer passed to find_data_references_in_loop. Alignment of
data-ref is now represented (in data reference structure) by two fields
MISALIGNMENT and ALIGNED_TO. Since during the computation the required
alignment is unknown, we record the biggest possible alignment in
ALIGNED_TO and then check it in the vectorizer.

Another comment from Daniel was that this patch also makes ltrans-8.c from
autovect branch work on mainline.

Ira

Patch:
(See attached file: patch.new)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.new
Type: application/octet-stream
Size: 181103 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20050719/841c6317/attachment.obj>


More information about the Gcc-patches mailing list