non compiler portable syntax in indexing _m256 etc... about grid

[paboyle]

Oops, we picked up a regression fail in Grid_simd under AVX

Peters-MacBook-Pro:clang-avx pab$ ./tests/Grid_simd

Testing vComplexF

timesI
OK!
timesMinusI
OK!
Plus
OK!
Minus
OK!
Times
OK!
Conj
OK!
Adj
OK!
innerProduct
OK!
Reduce

---

1.42957 (2.62148,2.91105) (1.93744,4.16634)
Assertion failed: (ok==0), function ReductionTester, file ../../../tests/Grid_simd.cc, line 179.
Abort trap: 6

[coppolachan]

I corrected and tested the regression fail for AVX. it is ok now. Pushed.
Also corrected the Intel compiler by adding a union, but untested.

[paboyle]

I patched some more of the indexing issues in the simd code; and think this is now clean.

ICPC still doesn't work with the new code, though under AVX and SSE4.

It is choking on the "EnableIf" portions of Grid_vector_types.h

Just in case things improved, I downloaded (free) ICPC v16.0 beta from Intel site, 3 month registration is allowed. But this is still failing.

icpc -DHAVE_CONFIG_H -I. -I../../../lib    -I../../../ -mavx -O3 -std=c++11 -MT Grid_init.o -MD -MP -MF $depbase.Tpo -c -o Grid_init.o ../../../lib/Grid_init.cc &&\
mv -f $depbase.Tpo $depbase.Po

../../../lib/simd/Grid_vector_types.h(133): error: no instance of "vsplat" matches the argument list
argument types are: (Grid::Grid_simdstd::__1::complex<float, Grid::SIMD_Ftype>, double, double)
friend inline void vzero(Grid_simd &ret) { vsplat(ret,0.0,0.0); }// use xor?
^
detected during:
instantiation of "void Grid::zeroit(Grid::Grid_simd<scalar_type, vector_type> &) [with scalar_type=std::__1::complex, vector_type=Grid::SIMD_Ftype]" at line 251 of "../../../lib/math/Grid_math_tensors.h"
instantiation of class "Grid::iMatrix<vtype, N> [with vtype=Grid::vComplex, N=3]" at line 55 of "../../../lib/math/Grid_math_tensors.h"
instantiation of class "Grid::iScalar [with vtype=Grid::iMatrix<Grid::vComplex, 3>]" at line 143 of "../../../lib/math/Grid_math_tensors.h"
instantiation of class "Grid::iVector<vtype, N> [with vtype=Grid::iScalar<Grid::iMatrix<Grid::vComplex, 3>>, N=4]" at line 138 of "../../../lib/math/Grid_math_tensors.h"
instantiation of "Grid::iVector<vtype, N> &Grid::iVector<vtype, N>::operator=(const Grid::Zero &) [with vtype=Grid::iScalar<Grid::iMatrix<Grid::vComplex, 3>>, N=4]" at line 222 of "../../../lib/lattice/Grid_lattice_base.h"
instantiation of "Grid::Lattice &Grid::Lattice::operator=(const sobj &) [with vobj=Grid::QCD::vLorentzColourMatrix, sobj=Grid::Zero]" at line 414 of "../../../lib/parallelIO/GridNerscIO.h"
instantiation of "void Grid::readNerscObject<vobj,sobj,fobj,munger>(Grid::Lattice &, std::__1::string, munger, int, std::__1::string &) [with vobj=Grid::QCD::vLorentzColourMatrix, sobj=Grid::QCD::LorentzColourMatrix, fobj=Grid::LorentzColour2x3F, munger=Grid::Nersc3x2munger<Grid::LorentzColour2x3F, Grid::QCD::LorentzColourMatrix>]" at line 523 of "../../../lib/parallelIO/GridNerscIO.h"

compilation aborted for ../../../lib/Grid_init.cc (code 2)
make[2]: *** [Grid_init.o] Error 2
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1

Obviously, since we're targeting KNL and the AVX512 support is only complete with Intel's compiler
to date we need the code to work with this compiler.

[paboyle]

Think I have a work around.... has taken HOURS....

[paboyle]

ICPC doesn't like the
template < class S=Scalar_type, EnableIf<>...
syntax. Replaced by moving template functions out of class and
explicit

template<class S,class V, EnableIf< Condition,int > = 0 > function( Grid_simd<S,V> )

kind of approach. This looks like it compiles clean.

[coppolachan]

Sorry for the extra work. I do not have the intel compiler here yet.

[paboyle]

Not worried about the extra work -- was worried that it might not be possible to make icpc
happy with what still looks to me like legal code.

C++11 is a bit patchy across the board still.

We lost g++ due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66153

As an aside, I worry about getting ourselves into being so close the language frontiers that
we lose portability. Loss of compiler portability (and -fpermissive is a bad habit)
crippled Chroma on BG/Q. Don't care whether it was IBM's compiler or Chroma's fault.

De facto it didn't compile on the best compiler for the system, and quibbling about language
compliance and finger pointing didn't solve the problem.

[coppolachan]

Ok, let's be careful in testing the code on several target compilers after adding complex syntax. Or testing directly on icpc which seems to be the most strict one.