Clang 3.1 __builtin_ia32_pcmpeqd128 doesn't work anymore

Hi,

I recently migrate from llvm/clang 2.8 to 3.1.
The builtin __builtin_ia32_pcmpeqd128 compile and works perfectly with clang 2.8.
But with clang 3.1, i get the compilation error :

use of unknown builtin ‘__builtin_ia32_pcmpeqd128’ [-Wimplicit-function-declaration]
__v4i comp = __builtin_ia32_pcmpeqd128(vectTag, vectTag2);

(cf dummy.c → clang -c dummy.c -o dummy.o)

Is that normal? Is there an other way to do it?

Thanks in advance
Christophe

dummy.c (444 Bytes)

Hi Christophe,

I recently migrate from llvm/clang 2.8 to 3.1.
The builtin __builtin_ia32_pcmpeqd128 compile and works perfectly with clang 2.8.
But with clang 3.1, i get the compilation error :

use of unknown builtin '__builtin_ia32_pcmpeqd128' [-Wimplicit-function-declaration]
        __v4i comp = __builtin_ia32_pcmpeqd128(vectTag, vectTag2);

(cf dummy.c -> clang -c dummy.c -o dummy.o)

Is that normal? Is there an other way to do it?

I think it was removed because you can get the same effect using generic IR:
a "icmp eq" of the vectors, followed by a "sext" to the result type.

Ciao, Duncan.

Thanks for the answer,

So if i understand right, i can’t directly compile the c code using clang.
And i need to manually generate some llvm ir to replace the builtin function.

Is that right?

2012/6/4 Duncan Sands <baldrick@free.fr>

Hi Christophe,

So if i understand right, i can't directly compile the c code using clang.
And i need to manually generate some llvm ir to replace the builtin function.

Is that right?

I think so, though I don't know much about clang's support for such intrinsics,
just what's in http://clang.llvm.org/compatibility.html#vector_builtins

Ciao, Duncan.

Hi Christophe,

> So if i understand right, i can't directly compile the c code using
> clang. And i need to manually generate some llvm ir to replace the
> builtin function.
>
> Is that right?

I think so, though I don't know much about clang's support for such
intrinsics, just what's in
http://clang.llvm.org/compatibility.html#vector_builtins

I think that you should write to the cfe-dev list about this. Just
because the LLVM intrinsic was removed does not mean that the clang
intrinsic cannot exist. clang should be able to generate the
aforementioned generic IR.

-Hal

Hi Hal,

I think so, though I don't know much about clang's support for such
intrinsics, just what's in
http://clang.llvm.org/compatibility.html#vector_builtins

I think that you should write to the cfe-dev list about this. Just
because the LLVM intrinsic was removed does not mean that the clang
intrinsic cannot exist. clang should be able to generate the
aforementioned generic IR.

did you read the web-page I mentioned above?

Ciao, Duncan.

Hello

So if i understand right, i can't directly compile the c code using clang.
And i need to manually generate some llvm ir to replace the builtin
function.

This is gcc's internal builtin function which was removed from clang.

One should either use *mmintrin.h files (as specified by
http://clang.llvm.org/compatibility.html#vector_builtins) or do
something similar to this (just wild guess):
__v4i comp = (vectTag == vectTag2);

Hi Hal,

>> I think so, though I don't know much about clang's support for such
>> intrinsics, just what's in
>> http://clang.llvm.org/compatibility.html#vector_builtins
>
> I think that you should write to the cfe-dev list about this. Just
> because the LLVM intrinsic was removed does not mean that the clang
> intrinsic cannot exist. clang should be able to generate the
> aforementioned generic IR.

did you read the web-page I mentioned above?

No, and I apologize. Nevertheless, I still recommend that any further
questions on this topic be directed to cfe-dev. This is because there
is a decoupling between LLVM and clang intrinsics. Just because there
is no longer an LLVM intrinsic does not mean that there cannot be a
clang intrinsic (as you know, many of the existing clang intrinsics
generate generic IR now).

-Hal

Hi

__v4i comp = (vectTag == vectTag2); seems to work,

Thanks everyone.

2012/6/4 Hal Finkel <hfinkel@anl.gov>