This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fw: [patch] [4.2 projects] vectorize strided accesses (4 patches)
- From: Diego Novillo <dnovillo at redhat dot com>
- To: Ira Rosen <IRAR at il dot ibm dot com>
- Cc: gcc-patches at gnu dot org, Victor Kaplansky <VICTORK at il dot ibm dot com>
- Date: Tue, 05 Sep 2006 09:48:29 -0400
- Subject: Re: Fw: [patch] [4.2 projects] vectorize strided accesses (4 patches)
- References: <OFBCA85117.121EA994-ONC22571E0.002AF8B8-C22571E0.003257B3@il.ibm.com>
Ira Rosen wrote on 09/05/06 05:09:
>> What about ALIGN_INDIRECT_REF and MISALIGNED_INDIRECT_REF? Could
>> those be handled?
>
> Probably they could. We will think it over. It is a data ref analysis
> issue though, it should be in a different patch, I think.
>
Agreed. Let's first get this one out of the way.
> I am sorry, I don't understand your remark. Maybe I can rephrase in
> the following way:
>
> /* The first location accessed by data-ref in the loop is the
> address of data-ref's base (BASE_ADDRESS) plus the initial offset
> from the base. We divide the initial offset into two parts: loop
> invariant offset (OFFSET) and constant offset (INIT). STEP is the
> stride of data-ref in the loop in bytes.
>
Ah, yes. That's pretty good, thanks.
>>> + if (tree_int_cst_compare (next_init, DR_INIT (dra)) > 0)
>>>
>> Are we positive at this point that DR_INIT will always have
>> INTEGER_CSTs? This happens a few times in other functions.
>
> Yes we are. When a DR is created in create_data_ref the constant part
> of the offset is put in DR_INIT.
>
OK, good.
> Vectorized loads are created in the order of memory accesses starting
> from the access of the first stmt of the chain:
>
> Is this more clear?
>
Yes, thanks.
> Is it O.K. for mainline 4.3 with those changes?
>
Sure.