http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55448
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |uros at gcc dot gnu.org
Target Milestone|--- |4.8.0
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-23
17:50:56 UTC ---
With -O2 -mavx -fno-ipa-sra the whole
#include <x86intrin.h>
static inline __m256
add1 (const __m256 & a, const __m256 & b)
{
return _mm256_add_ps (a, b);
}
void
f1 (__m256 & a, const __m256 b)
{
a = add1 (a, b);
}
static inline __m128
add2 (const __m128 & a, const __m128 & b)
{
return _mm_add_ps (a, b);
}
void
f2 (__m128 & a, const __m128 b)
{
a = add2 (a, b);
}
static inline __m256
add3 (const __m256 *a, const __m256 *b)
{
return _mm256_add_ps (*a, *b);
}
void
f3 (__m256 *a, const __m256 b)
{
*a = add3 (a, &b);
}
static inline __m128
add4 (const __m128 *a, const __m128 *b)
{
return _mm_add_ps (*a, *b);
}
void
f4 (__m128 *a, const __m128 b)
{
*a = add4 (a, &b);
}
testcase compiles into optimal code. Beyond the eipa_sra issue the thing is
that for AVX/AVX2 we generally should attempt to combine unaligned loads with
operations that use them (unless it is a plain move), but there is UNSPEC_LOADU
involved (and for 256-bit values also vec_concat with another MEM load), so not
sure what would be the best pass to handle that, if some hack in the combiner,
peephole2 (but we'd need many of them) or what.
