http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #3 from ktkachov at gcc dot gnu.org ---
> So maybe we should add some optimization level to the existing tests in the
> meantime?
Transforming them into something like
#include "arm_neon.h"
volatile int16x8_t arg0_int16x8_t;
volatile int16x8_t arg1_int16x8_t;
int16x8_t test_vbicQs16 (void)
{
int16x8_t out_int16x8_t;
return vbicq_s16 (arg0_int16x8_t, arg1_int16x8_t);
}
seems to work at -O2 (i.e. generates vbic and doesn't optimise away the whole
test), so it could be a way to go if the maintainers want it.
To be a bit pedantic, the ACLE spec doesn't strictly require the intrinsics
that the particular NEON instruction is generated, just that the functionality
is as defined in the spec (although the NEON instruction is likely to be the
optimal implementation of that functionality).
Do we plan to keep these scan-assembler tests? or go with just functional
tests?
