Any way to make "unsupported data type" a warning rather than error for elemental function (ICC as codegen target)

[ryannewton]

I'm trying to use ICC as a target for program synthesis.  With machine generated code its important that I not get extra vectorization related error messages that cause the system to break.  With loop pragmas we have both hints that help vectorization (#pragma ivdep) and mandates that insist upon it (#pragma simd).  However, it seems like with elemental functions (__declspec(vector)) there is no way to achieve graceful failure (i.e. fallback to sequential code) when a problem arises.

In particular I get "unsupported data type" errors from the elemental function.  Is there any way to turn these into warnings?

The alternative is to make my program synthesis tool understand all the ICC rules for what is and is not vectorizable, which seems like a seriously bad idea.

[SergeyKostrov]

>>...In particular I get "unsupported data type" errors from the elemental function... Could you provide more technical details, please? >>Is there any way to turn these into warnings? Opposite is possible, that is Warnings-to-Errors, but Errors-to-Warnings I don't think so. Any C++ compiler needs to generate some instructions and if it can't do that an Error is generated. Now, let's assume that some C++ compiler allows to turn On some Error-to-Warning feature. So, what instructions should be generated if some codes generate a Warning, that was previously an Error?

[ryannewton]

Hi Sergey,

Thanks for your response.  Yes, certainly there are some errors which would be fatal no matter what.  However, with the compiler's vectorization features there is always the option of generating sequential instructions instead, which is the behavior I would like in this case.

I've attached a file (of generated code) with a simple example.  If you set "my_t" to int, the program compiles, if you set it to long, it errors.  The vectorizer cannot handle writing to an array of longs (64 bit on this machine) inside an elemental function.  It complains with:

debug.c(16): (col. 1) remark: function was not vectorized: unsupported data type.
debug.c(16): (col. 1) error #13397: vector function was not vectorized
debug.c(31): (col. 5) remark: function was not vectorized: unsupported data type.
debug.c(16): (col. 1) error #13397: vector function was not vectorized

To reproduce that you can compile with "icc -w -std=c99 debug.c" (or add -fast).

[ryannewton]

Actually here's another example which is even harder to predict (from the perspective of the code generator).  This line breaks vectorization:

if ((bool)(!((bool)((bool)(e11 == e12) && (bool)((bool)(e8 == e7) && (bool)(e10 == e9))))))

But deleting the casts makes it ok:

  if ((!(((e11 == e12) && ((e8 == e7) && (e10 == e9))))))

Ok, so I can start putting in a pile of hacks, but to target something with a compiler it really needs to have a clear language definition (what's supported, what's not) OR there has to be the option of failover to sequential code.

[SergeyKostrov]

>>... If you set "my_t" to int, the program compiles, if you set it to long, it errors... It looks like a bug with the Intel C++ compiler and thanks for the report.

[Melanie_B_Intel]

Hi Ryan,
The message that you report is a discretionary error (you can tell this because we give a diagnostic number) you can easily downgrade this to a warning with -diag-warning 13397 or disable it entirely with -diag-disable 13397

[SergeyKostrov]

Melanie, >>...The message that you report is a discretionary error (you can tell this because we give a diagnostic number)... What is a range of numbers for these discretionary errors? Thanks in advance.

[Melanie_B_Intel]

There's no numeric range for "discretionary errors". If you see an error diagnostic print with an error number, e.g. "error #13397", then you can modify the error diagnostic into a warning diagnostic using -diag-warning. If an error diagnostic is not discretionary, then the diagnostic number will not appear in the message. 

[SergeyKostrov]

>>...There's no numeric range for "discretionary errors". If you see an error diagnostic print with an error number, e.g. "error #13397", >>then you can modify the error diagnostic into a warning diagnostic using -diag-warning... Thank you for the explanation!

[ryannewton]

Yes, thanks Melanie!  This works great.