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: Fw: [patch] [4.2 projects] vectorize strided accesses (4 patches)


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.


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