This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] (4.1 project list) vectorizer alignment improvements


On Mon, May 30, 2005 at 07:16:35PM +0300, Dorit Naishlos wrote:
> !   if (dist % vectorization_factor == 0)
>       {
> !       /* Two references with distance zero have the same alignment.  */
> !       VEC_safe_push (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmtinfo_a), drb);
> !       VEC_safe_push (dr_p, heap, STMT_VINFO_SAME_ALIGN_REFS (stmtinfo_b), dra);
> !       if (vect_print_dump_info (REPORT_ALIGNMENT, LOOP_LOC (loop_vinfo)))
----
> + 	STMT_VINFO_SAME_ALIGN_REFS (vinfo_for_stmt (DR_STMT (dr0)));
> +       for (i = 0; VEC_iterate (dr_p, same_align_drs, i, dr); i++)
> +         {
> +           DR_MISALIGNMENT (dr) = 0;

So we find two references, and see that they're offset from one another
by a multiple of the vector size.  Fine.  Presumably this later forcing
of the alignment to zero comes after loop peeling to align one of the
references, and we're remembering that the other references shared the
same relative alignment.

What I don't understand is how this works except in the special case of
only one pair found.  In which case you don't need a queue like this.

I'm thinking of something like

	for (i = 0; i < N; ++i) {
	  a[i] += a[i+4];
	  b[i+1] += b[i+5];
	}

or something like that.  The point being that a[i] and a[i+4] are 4
units apart, as are b[i+1] and b[i+5].  But a[i] and b[i+1] are not
co-aligned, which would seem to break the bulk processing that you're
doing here.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]