5.21 source compilable with ICC anywhere?

[maverick]

Hi all,

I'm looking for sources of s@h_enhanced 5.21, compilable with ICC.  Current sources give full of intrinsics errors, even intrinsics are disabled.(and that Eric doesn't guarantee ICC w/o intrinsics works).  And that it should be compiled on Window$ also.  And that currently it's still under development...

Then anyone (me?) must edit intrinsics.....

regards,

-Tetsuji

[Crunch3r]

Hi all,

I'm looking for sources of s@h_enhanced 5.21, compilable with ICC.  Current sources give full of intrinsics errors, even intrinsics are disabled.(and that Eric doesn't guarantee ICC w/o intrinsics works).  And that it should be compiled on Window$ also.  And that currently it's still under development...

Then anyone (me?) must edit intrinsics.....

regards,

-Tetsuji

Hi TMR, 

It's not exactly a 5.21 source but 5.21 is based on our 2.4 source tree
I mailed Simon so that you get access to the development source

I'm really happy to see you here my friend 

[Simon]

Hi Tetsuji,

good to see you here! I've given you access to the pre-release section, there are some Linux source tarballs available there.

As for ICC-compatible sources, right now we have just our current codebase which works on Linux and Windows but is still based on 5.15 with some Multibeam edits.

Sources based on 5.21 haven't even begun to compile for me, either...no matter whether with MSVC or ICC.

Regards,
Simon.

[maverick]

Hi, Crunch3r & Simon,

Thank you for warm welcome!

And thank you for the source 2.4.  However it looks like it's still developing (at least Alex seems to developing AKfoldSSE.cpp which isn't present yet!  AK stands for Alex Kan, right?).

[Josef W. Segur]

Hi, Crunch3r & Simon,

Thank you for warm welcome!

And thank you for the source 2.4.  However it looks like it's still developing (at least Alex seems to developing AKfoldSSE.cpp which isn't present yet!  AK stands for Alex Kan, right?).

You are indeed welcome here.

The origin of AKfoldSSE was Alex's 6.x SSE2 folding routine, but I adapted it to my folding scheme sometime last year. The .cpp file should be in the 2.4 sources Optimizer directory.

All intrinsics I've used have been per Intel instruction set documentation, they should work with the Intel compiler. Simon and Crunch3r have been able to take what I've written and tested with DevC++/MinGW and get it working with their Intel builds fairly quickly. But I think they have moved to very recent versions of the Intel tools.
                                                                                   Joe

[maverick]

You are indeed welcome here.

The origin of AKfoldSSE was Alex's 6.x SSE2 folding routine, but I adapted it to my folding scheme sometime last year. The .cpp file should be in the 2.4 sources Optimizer directory.

All intrinsics I've used have been per Intel instruction set documentation, they should work with the Intel compiler. Simon and Crunch3r have been able to take what I've written and tested with DevC++/MinGW and get it working with their Intel builds fairly quickly. But I think they have moved to very recent versions of the Intel tools.
                                                                                   Joe

Thank you!  But actually ICC rejects some of the intrinsics.  They don't seem 100% compatible.  So we need to use intrinsics modified for ICC.(why aren't they compatible?).   The problem is incompatibility of argument types.  For example

Code: [Select]

vector/analyzeFuncs_sse.cpp(803): error: argument of type "x86_m128={__m128}" is incompatible with parameter of type "__m128"
          s = _mm_add_ps(s, SS2);
                         ^


vector/analyzeFuncs_sse.cpp(803): error: argument of type "const_float4" is incompatible with parameter of type "__m128"
          s = _mm_add_ps(s, SS2);
                            ^

vector/analyzeFuncs_sse.cpp(803): error: a value of type "__m128" cannot be assigned to an entity of type "x86_m128={__m128}"
          s = _mm_add_ps(s, SS2);
            ^

I don't see anything wrong and I'm at a loss, but once solved, it will be easy.

Thanks in advance.

[edit]
I made a small test program as follows:

Code: [Select]

#define __SSE__
#define __MMX__

#include <xmmintrin.h>

__m128 a,b,c;

void
func(){
  a = _mm_add_ps(b,c);
}
g++ gives a lot of errors, while ICC compiles this w/o any errors (output code is as expected).....ICC looks generous.

[Josef W. Segur]

...
The problem is incompatibility of argument types.  For example

Code: [Select]

vector/analyzeFuncs_sse.cpp(803): error: argument of type "x86_m128={__m128}" is incompatible with parameter of type "__m128"
          s = _mm_add_ps(s, SS2);
                         ^


vector/analyzeFuncs_sse.cpp(803): error: argument of type "const_float4" is incompatible with parameter of type "__m128"
          s = _mm_add_ps(s, SS2);
                            ^

vector/analyzeFuncs_sse.cpp(803): error: a value of type "__m128" cannot be assigned to an entity of type "x86_m128={__m128}"
          s = _mm_add_ps(s, SS2);
            ^

I don't see anything wrong and I'm at a loss, but once solved, it will be easy.

Thanks in advance.
...

The x86_m128 type shouldn't be in use in that module, it looks like xmmintrin.h isn't being included at the top of x86_ops.h so __m128 is being replaced by x86_m128 at the bottom. For a Linux build, the sah_config.h file should have a line
#define HAVE_XMMINTRIN_H 1

That line was added June 1, but changes in that file aren't showing on the [seti_cvs] list, the most recent is June 18. I suppose that's because the file should be auto-generated rather than manually edited.

I don't know if that will resolve the issue with const_float4 types. Those are Eric's method of ensuring that the compiler won't generate SSE initialization code for vector constants, running SSE before entry to main() and crashing on systems which don't have SSE. If they continue to be a problem, maybe copying those constants as is done in analyzeFuncs_x86_64.cpp will be necessary, but I'd try casting them first.
                                                                                        Joe

[maverick]

The x86_m128 type shouldn't be in use in that module, it looks like xmmintrin.h isn't being included at the top of x86_ops.h so __m128 is being replaced by x86_m128 at the bottom. For a Linux build, the sah_config.h file should have a line
#define HAVE_XMMINTRIN_H 1

That line was added June 1, but changes in that file aren't showing on the [seti_cvs] list, the most recent is June 18. I suppose that's because the file should be auto-generated rather than manually edited.

I don't know if that will resolve the issue with const_float4 types. Those are Eric's method of ensuring that the compiler won't generate SSE initialization code for vector constants, running SSE before entry to main() and crashing on systems which don't have SSE. If they continue to be a problem, maybe copying those constants as is done in analyzeFuncs_x86_64.cpp will be necessary, but I'd try casting them first.
                                                                                        Joe

Hi Joe,

Thank you for the hint. but defining "#define HAVE_XMMINTRIN_H 1" and "#include <xmmintrin.h>  near the top of x86_ops.h doesn't work.   So I may need to try casting, but if so, there are a LOT of these codes....sigh.   I wonder how others avoid this.

[edit]
somehow, casting doesn't work, either....

Code: [Select]

vector/analyzeFuncs_sse.cpp(803): error: argument of type "x86_m128={__m128}" is incompatible with parameter of type "__m128"
          s = (__m128)_mm_add_ps((__m128)s, (__m128)SS2);
                                 ^

vector/analyzeFuncs_sse.cpp(803): error: argument of type "x86_m128={__m128}" is incompatible with parameter of type "__m128"
          s = (__m128)_mm_add_ps((__m128)s, (__m128)SS2);
                                            ^

vector/analyzeFuncs_sse.cpp(803): error: type of cast must be integral or enum
          s = (__m128)_mm_add_ps((__m128)s, (__m128)SS2);
               ^



[Josef W. Segur]

One thing I didn't consider was that if xmmintrin.h wasn't included you'd be seeing errors on the intrinsic functions as well as their arguments.

If you haven't tried it already, just comment out those 3 lines at the end of x86_ops.h which make the preprocessor rewrite __m128 to x86_m128 in the project source. It seems that has to be what's causing the problem, technically #ifndef only works for preprocessor macro definitions and maybe Intel has implemented __m128 in some other way.

If that helps we can think about rewriting the conditional more compatibly.
                            &nbqp;                                                            Joe

[maverick]

Hi Joe,

Thanks!  That's it.  I didn't see the last part!   I fixed like:

Code: [Select]

#ifndef __INTEL_COMPILER
#ifndef __m128d
#define __m128d x86_m128d
#endif

#ifndef __m128i
#define __m128i x86_m128i
#endif

#ifndef __m128
#define __m128 x86_m128
#endif

Now I got other errors...

[maverick]

Hi,

Next one is nothing to do with me (because it's em64t), but the error codes are

Code: [Select]

vector/analyzeFuncs_x86_64.cpp(76): error: a value of type "__m128" cannot be assigned to an entity of type "x86_m128={__m128}"
      zz = _mm_setzero_ps ();
         ^

vector/analyzeFuncs_x86_64.cpp(120): error: a value of type "__m128d" cannot be assigned to an entity of type "x86_m128d={__m128}"
                  CC = _mm_loadu_pd (aC);
                     ^

vector/analyzeFuncs_x86_64.cpp(121): error: a value of type "__m128d" cannot be assigned to an entity of type "x86_m128d={__m128}"
                  DD = _mm_loadu_pd (aD);
                     ^

vector/analyzeFuncs_x86_64.cpp(123): error: argument of type "x86_m128d={__m128}" is incompatible with p!bameter of type "__m128d"
                  cc = _mm_cvtpd_ps (CC);
                                     ^

I'm thinking of deleting this one.  The first
#if defined(__i386__) || defined(__x86_64__) || defined (_M_AMD64) || defined(_M_IX86)
is the problem.  May I trim it to
#if defined(__x86_64__) || defined (_M_AMD64) ?

[Josef W. Segur]

Eric included the (__i386__) in that sequence, maybe for a good reason I don't understand. I suggest an && !defined (__INTEL_COMPILER) approach.

That chirp method is glacially slow anyhow, at least on my Intel based systems. And if a compiler actually restricted the time and ang variables to single precision float it would be unacceptably inaccurate (as used, calculations involving those will almost certainly be kept in FPU registers and be OK).
                                                                                      Joe

[maverick]

Thanks.

I compiled and ran it, but it gives computation errors....I must have done something wrong or it's not ready yet....   Anyway I'd better use source 2.4 here (I've been using s@h's nightly tarball).

Just a moment.  There is an intel compiler for em64t....