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, testsuite]: Fix recent vect testsuite failures on x86_64


On 7/16/07, Dorit Nuzman <DORIT@il.ibm.com> wrote:
> Hm, for pr25413a.c, it looks that malloc on 32bit targets doesn't
> return correctly aligned address that would satisfy vectorizer
> constraint. However - if we can detect this, could we use unaligned
> loads in this case?
>

Not sure I understand what you're asking - in pr25413a.c there are no
loads, only a store. In general, we could and we do use unaligned loads
when we need to. It's just that currently unaligned stores are not
implemented and the way we deal with it is by peeling the loop to align the
store (and if that's not doable, we do loop versioning).

Oh, I didin't notice that it is a _store_ there. The writings above answers what I was trying to ask... (thanks!).

To stay on topic, even when accessed throug pointer, we are still
dealing with an array of the vaules of the same type (otherwise
vectorizer won't try to vectorize access to them). OTOH, malloc always
returns 16-byte aligned chunks on x86_64, so stores to mallocated
arrays can always be vectorized even for the current situation where
unaligned stores are not implemented.

(I guess that target_vect_aligned_arrays checking can be removed once
unaligned stores will be implemented, so this issue is kind of
temporary).

Uros.


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