What does /Qvec do except vectorizing loops?

[Nikita_Tropin]

Hello,

I'm trying to optimize some scientific code, where Fortran DLL is called from C#. When I compile my Fortran DLL in Release with /O1 option or below, it works fine, but when I compile the DLL with /O2 or higher, I have an error during the runtime, right at the line that  calls Fortran DLL subroutine from C#:

"Attempted to read or write protected memory. This is often an indication that other memory is corrupt.".

So, following this thread, I found that the problem is in vectorization, i.e. when I disable it and build my DLL with /O2 and /Qvec-, it works fine. 

Then I decided to find out, which loop is causing problems, so with vectorization enabled I used vectorization report (/Qvec-report1) that showed me, which loops were vectorized. So I started to put a directive !DEC$ NOVECTOR before each such loop, rebuild the code and see it if works or not. I expected that after disabling vectorization of some specific loop, the program will start to work without errors. However surprisingly I put NOVECTOR directive before each loop reported by Qvec-report, and the program still doesn't work!

So I have the situation where  /Qvec-report1 shows nothing, i.e. no loops are vectorized, but the program is not in the same state as when disabling vectorization at all with /Qvec-. So I suspect that /Qvec do something else except vectorization of loops, can you please advice on that.

I'm using  Intel(R) Visual Fortran Compiler XE 14.0.2.176 [IA-32] on Windows 7 x64.

Also, I have another question -what is the difference between /Qvec and /Qsimd options?

[Steven_L_Intel1]

It is probable that the problem isn't vectorization but rather that vectorization changes the code to reveal an issue elsewhere. The first thing I would check is whether you have the calling conventions in agreement between C# and Fortran. What is the declaration in C# of the Fortran routine and what is the Fortran routine declaration? Which Fortran compiler options are you using? Can you provide a test case?

[Nikita_Tropin]

Sorry for the delay in answer, I was trying to figure out the reason of the problem. It seems now that the root of the problem is not in vectorization but in operations with floating point numbers. With option /fp:fast2 my app crashes somewhere in the middle of the code with strange results, with /fp:fast it works fine, but each run gives slightly different results, and with /fp:source it works as expected with reproducible results (even with vectorization enabled).

[TimP]

I don't know whether you are asking about this, but I'll comment anyway.

I prefer not to set /fp:fast=2 but instead to set individual aspects of it if they seem worth trying:

/Qcomplex-limited-range   for shortcuts in complex divide, sqrt, and abs().  As the name implies, this will break an application which needs more than half of the full exponent range.  In my opinion, this option is more viable for double than single precision complex.  As I've noted before, /Qvec-report doesn't tell you about the effects this has on vectorization.  Without the shortcuts, even though a loop reports vectorized, it may spend all its time in serial implementation to avoid risk of failure in corner cases.

/Qimf-domain-exclusion:common [etc.] for some shortcuts in vectorized sqrt and divide (but, on the Xeon CPUs, you may choose the safest setting /Qprec-div /Qprec-sqrt in order to enforce IEEE implementation, as the current Xeon CPUs implement this efficiently).

/fp:source eliminates optimizations which are expected to produce results where roundoff varies with data alignment (most importantly, vectorized sum reduction, which usually improves accuracy, but by an unpredictable degree).  You may want this option if your application doesn't spend significant time where these optimizations are relevant, or, of course, if you are trying to isolate numerical issues.