llvm dev - Dec 2009 - [LLVMdev] problem compiling x86 intrinsic function

I am trying to compile this little C-program:
================typedef double        v2f64 __attribute__((ext_vector_type(2)));

   int sse2_cmp_sd(v2f64, v2f64, char ) asm("llvm.x86.sse2.cmp.sd");

int main()
{

  static int i;
  static float x[10];
  static float y[10];
  v2f64 m1;
  v2f64 m2;

  int j;
 
    i = sse2_cmp_sd(m1,m2,'z');
=========================I expected to see inline code for one of the X86
intrinsic functions. However, when I looked
at the *.ll file I see this function declared as

declare i32 @"\01llvm.x86.sse2.cmp.sd"(<2 x double>, <2 x
double>, i8 signext)


with extra "01" character in front of the name. Subsequently this
function does not match the intrinsic function
name and the resulting code produces a call to "llvm.x86.sse2.cmp.sd"
function instead of inline code.

Is my C-program incorrect?

Thanks.

On Dec 29, 2009, at 5:50 AM, fima rabin wrote:
> I am trying to compile this little C-program:
> ================> typedef double        v2f64
__attribute__((ext_vector_type(2)));
> 
>   int sse2_cmp_sd(v2f64, v2f64, char )
asm("llvm.x86.sse2.cmp.sd");
We used to support this, but there are problems with it.  I actually just went
to go implement this again, which illustrated why this is a bad idea.  If you
apply this patch to clang, it will do what you want:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p.patch
Type: application/octet-stream
Size: 1040 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091229/34ec1dd0/attachment.obj>
-------------- next part --------------


The problem with this is that the optimizer and code generator will explode if
the generated intrinsic has the wrong attributes or type.  In this case, you
have both problems.

Depending directly on llvm intrinsics is also a dangerous thing to do because
they are allowed to change over time.  I don't think we want the compiler
exposing them directly.  If you need something, there should be a __builtin that
corresponds to the intrinsic.

-Chris

Thanks for your advice.

I am not sure that I understood your comment "If you need something, there
should be a __builtin that corresponds to the intrinsic." Is that a better
way to define an intrinsic function in C? How do you do it?

I am actually trying to add several intrinsic functions for my target machine so
I am looking for a simple and workable way of doing it.

Thanks again.

-- Fima



----- Original Message ----
From: Chris Lattner <clattner at apple.com>
To: fima rabin <fimarn at yahoo.com>
Cc: LLVMdev at cs.uiuc.edu
Sent: Tue, December 29, 2009 2:57:27 PM
Subject: Re: [LLVMdev] problem compiling x86 intrinsic function


On Dec 29, 2009, at 5:50 AM, fima rabin wrote:
> I am trying to compile this little C-program:
> ================> typedef double        v2f64
__attribute__((ext_vector_type(2)));
> 
>   int sse2_cmp_sd(v2f64, v2f64, char )
asm("llvm.x86.sse2.cmp.sd");
We used to support this, but there are problems with it.  I actually just went
to go implement this again, which illustrated why this is a bad idea.  If you
apply this patch to clang, it will do what you want:


The problem with this is that the optimizer and code generator will explode if
the generated intrinsic has the wrong attributes or type.  In this case, you
have both problems.

Depending directly on llvm intrinsics is also a dangerous thing to do because
they are allowed to change over time.  I don't think we want the compiler
exposing them directly.  If you need something, there should be a __builtin that
corresponds to the intrinsic.

-Chris