size value of vector_size attribute

Chris Elrod elrodc@gmail.com
Mon Dec 16 17:52:00 GMT 2019


> I perfer m256 too.  I'm already using vector_size(4*sizeof(double)) for
some calculation in 3D euclid space (only 3 elements are really used).

Then I'd expect m256 to give you good performance for a lot of it; ie, 1
operation vs 2 (1x m128 and 1x m64) or 3 (3x m64).
I wish this was a trick compilers did more often. ISPC might, but I haven't
played with it as much as I'd like.

> I want SIMD code and I don't need much indexing.  But just curious, why
indexing SIMD vectors is inefficient?

If you don't do much indexing, it should be fine. Basically, to extract an
element, compilers seem to store the vector, and then load the desired
element.

Here are a couple simple examples:
https://godbolt.org/z/4EH_Nk

I used -O3 with gcc and clang.
index1 just indexes a pointer like normal. gcc and clang both use a single
vmovsd.
index2 loads a vector, and then indexes the vector. clang is able to reduce
that into being equivalent to index1, but gcc loads the vector, re-stores
the vector elsewhere, and then vmovsd from that stored vector.
index3 takes a vector as an argument, and then indexes it. Neither compiler
generated nice looking code here. They both stored the vector, and then
vmovsd to load the single element.

The index2 example with gcc was also particularly problematic, in that the
vector wasn't totally transparent to the optimizer.
Still, not a big deal if you don't do much indexing. If the autovectorizer
vectorized your scalar code, it would still have to resort to the same
tricks (storing a vector and reloading a scalar) to extract a scalar. So
you aren't losing anything.
Meaning it's probably totally fine, or much better than fine if the SIMD is
profitable.

On Mon, Dec 16, 2019 at 10:59 AM Xi Ruoyao <xry111@mengyan1223.wang> wrote:

> On 2019-12-16 08:16 -0500, Chris Elrod wrote:
> > I'm not the asked, but I would strongly prefer m256 if code could be
> > generated masking the unused lane for safe loads/stores, at least on
> > architectures where this is efficient (eg, Skylake-X).
> > This automatic masking would make writing SIMD code easier when you
> > don't
> > have powers of 2, by saving the effort of passing the bitmask to each
> > operation (which is at least an option with intrimin.h, not sure
> > about
> > GCC's built-in).
>
> I perfer m256 too.  I'm already using vector_size(4*sizeof(double)) for
> some calculation in 3D euclid space (only 3 elements are really used).
>
> > However, if the asker doesn't want this for SIMD code, but wants a
> > convenient vector to index for scalar code, I'd recommend defining
> > your own
> > class. Indexing SIMD vectors is inefficient, and it may interfere
> > with
> > optimizations like SROA. But I could be wrong; my experience is
> > mostly with
> > Julia which uses LLVM. GCC may do better.
>
> I want SIMD code and I don't need much indexing.  But just curious, why
> indexing SIMD vectors is inefficient?
> --
> Xi Ruoyao <xry111@mengyan1223.wang>
> School of Aerospace Science and Technology, Xidian University
>
>

-- 
https://github.com/chriselrod?tab=repositories
https://www.linkedin.com/in/chris-elrod-9720391a/



More information about the Gcc-help mailing list