Vc issue

[Duhem, Laurent]

Ok - thx Matthias



I'll escalate this - will keep you posted.



Regards;


[image001]
[please enable javascript to see the address][please enable javascript to see the address]>
• Office:        +33 158877271
• Mobile:       +33 621415972
________________________________

-----Original Message-----
[please enable javascript to see the address]]
Sent: Friday, September 11, 2015 4:51 PM
[please enable javascript to see the address]
Cc: Duhem, Laurent; Oertel, Klaus-Dieter
Subject: Re: Vc issue



Hi,



I just found a workaround in ICC's zmmintrin.h. If I #define __INTEL_COMPILER_USE_INTRINSIC_PROTOTYPES the old (and documented) interface is restored. See:

https://github.com/VcDevel/Vc/commit/f86080d0e0195257d3b2142ab7f13023d10cbc63



Maybe this helps to track down the issue in ICC.



Cheers,

  Matthias



On Thursday 10 September 2015 17:16:41 Matthias Kretz wrote:

> On Thursday 10 September 2015 14:15:02 Duhem, Laurent wrote:

> > I had a look at your ./mic/intrinsics.h file.

> >

> > Machine instruction for those kind of intrinsic have a field of 3

> > bits in the mnemonic to specify the conversion argument (so called

> > MVEX.SSS field) – same for the memory hint: the hint is represented by one bit ( MVEX.EH).

> >

> > Hence the compiler can’t generate the final machine instruction

> > unless the conversion and hit are a fixed compile time constant.

>

> I know. And that's the case here. The argument used for conv is a

> constant expression. And that's not the issue for the compilation

> error. ICC doesn't complain about the argument not being an immediate

> value - it doesn't even get so far as to check it. ICC fails earlier.

>

> This testcase should hopefully make it clear:

> #include <immintrin.h>

> struct A

> {

>     constexpr operator _MM_DOWNCONV_EPI32_ENUM() const { return

> _MM_DOWNCONV_EPI32_NONE; }

>     constexpr operator _MM_UPCONV_EPI32_ENUM() const { return

> _MM_UPCONV_EPI32_NONE; } };

>

> int f(_MM_DOWNCONV_EPI32_ENUM) { return 0; }

>

> int main()

> {

>     f(A());

>     _mm512_i32extscatter_epi32(nullptr, __m512i(), __m512i(), A(), 1, 0);

>     return 0;

> }

>

> The expression f(A()) is not ambiguous, while

> _mm512_i32extscatter_epi32(..., A(), ...) is. This would be impossible

> if the fourth parameter of

> _mm512_i32extscatter_epi32 were of type _MM_DOWNCONV_EPI32_ENUM. The

> compiler error says the parameter is of type unsigned int: 'error:

> more than one conversion function from "A" to "unsigned int" applies'.

>

> My complaint is about the type of the conv argument of

> _mm512_i32extscatter_epi32. It's unsigned int. It was

> _MM_DOWNCONV_EPI32_ENUM in previous ICC versions and it still is

> documented as _MM_DOWNCONV_EPI32_ENUM in the ICC 16 documentation.

>

> _______________________________________________

> Vc mailing list

>[please enable javascript to see the address][please enable javascript to see the address]>

> https://compeng.uni-frankfurt.de/mailman/listinfo/vc


---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://compeng.uni-frankfurt.de/pipermail/vc/attachments/20150914/3d42d661/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3299 bytes
Desc: image001.gif
URL: <http://compeng.uni-frankfurt.de/pipermail/vc/attachments/20150914/3d42d661/attachment.gif>