Julian Brown wrote on 05/11/2010 12:58:14 PM:
> I think it's probably fine to default to 128-bit vectors, and fall back
> to 64-bits when necessary (where access patterns block usage of wider
> vectors, or similar). AIUI, ARM were quite keen to get rid of
> -mvectorize-with-neon-quad altogether
On Wed, 3 Nov 2010 14:57:01 +0200
Ira Rosen wrote:
> > -mfloat-abi=softfp/-mfloat-abi=hard -mfpu=neon* [-march=armv7-a]
> >
> > * there are several variants for this, e.g. neon, neon-fp16,
> > neon-vfpv4 ... generally -mfpu=neon should do though, for Cortex-A8
> > chips at least.
>
> gcc.dg/vec
Julian Brown wrote on 03/11/2010 11:55:59 AM:
>
> On Mon, 1 Nov 2010 15:57:11 +0200
> Ira Rosen wrote:
>
> > It looks like it's enough to implement targetm.vectorize.
> > autovectorize_vector_sizes for NEON in order to enable initial
> > auto-detection of vector size. With the attached patch an
On Wed, Nov 3, 2010 at 2:55 AM, Julian Brown wrote:
> On Mon, 1 Nov 2010 15:57:11 +0200
> Ira Rosen wrote:
>> 3. According to gcc.dg/vect/vect.exp the only flag that is used for
>> NEON (in addition to target independent flags) is -ffast-math. Is
>> that enough?
Note that the NEON unit doesn't i
On Mon, 1 Nov 2010 15:57:11 +0200
Ira Rosen wrote:
> It looks like it's enough to implement targetm.vectorize.
> autovectorize_vector_sizes for NEON in order to enable initial
> auto-detection of vector size. With the attached patch and
> -mvectorize-with-neon-quad flag, the vectorizer first trie
Hi,
It looks like it's enough to implement targetm.vectorize.
autovectorize_vector_sizes for NEON in order to enable initial
auto-detection of vector size. With the attached patch and
-mvectorize-with-neon-quad flag, the vectorizer first tries to vectorize
for 128 bit, and if this fails, it tries
