Other Intrinsics?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Other Intrinsics?

Jon Sargeant
 > > Do you have plans to add other intrinsics?  I'm curious as to why there
 > > is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan
 > > intrinsic.  Why is there an llvm.pow intrinsic but no llvm.log
 > > intrinsic?
 >
 > Intrinsics get added on demand.  Generally there has to be a good reason
 > to add them.  llvm.sin was implemented (for example) to allow generation
 > of code that uses vector sin operations.

What is the criteria for adding an intrinsic or a built-in operation?
For example, could the 'frem' instruction be an intrinsic?  Could you
remove it from LLVM entirely and make it an external function?  What
distinguishes 'frem' from 'sin', 'pow', 'atan2', etc.?

Regards,
Jon
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Other Intrinsics?

Chris Lattner
On Tue, 27 Nov 2007, Jon Sargeant wrote:
> > Intrinsics get added on demand.  Generally there has to be a good reason
> > to add them.  llvm.sin was implemented (for example) to allow generation
> > of code that uses vector sin operations.
>
> What is the criteria for adding an intrinsic or a built-in operation?
> For example, could the 'frem' instruction be an intrinsic?  Could you
> remove it from LLVM entirely and make it an external function?  What
> distinguishes 'frem' from 'sin', 'pow', 'atan2', etc.?

Historically, intrinsics could not be overloaded, but instructions could.
However, intrinsics got more powerful, so this is no longer true.  There
is now very little distinction.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Other Intrinsics?

Dan Gohman
In reply to this post by Jon Sargeant
On Tue, Nov 27, 2007 at 10:50:03AM -0700, Jon Sargeant wrote:

>  > > Do you have plans to add other intrinsics?  I'm curious as to why there
>  > > is an llvm.sin intrinsic and an llvm.cos intrinsic, but no llvm.atan
>  > > intrinsic.  Why is there an llvm.pow intrinsic but no llvm.log
>  > > intrinsic?
>  >
>  > Intrinsics get added on demand.  Generally there has to be a good reason
>  > to add them.  llvm.sin was implemented (for example) to allow generation
>  > of code that uses vector sin operations.
>
> What is the criteria for adding an intrinsic or a built-in operation?
> For example, could the 'frem' instruction be an intrinsic?  Could you
> remove it from LLVM entirely and make it an external function?  What
> distinguishes 'frem' from 'sin', 'pow', 'atan2', etc.?

The main difference from my perspective between intrinsics and instructions
is that intrinsics don't require bitcode format changes. If someone wants an
atan2 intrinsic for example, it would be fairly easy, and we wouldn't have
to worry very much about collisions with other people adding new intrinsics,
where we would if we were adding new operators.

The main reason for adding intrinsics instead of just using C library
calls is for support for vector types. @llvm.sin.* can be overloaded as
@llvm.sin.v4f32, for example, which is very useful for some users.

The intrinsics for sin, cos, and pow are fairly new; I added them when
I implemented the support for vector types in intrinsics, to exercise this
new infastructure. It would be easy now to add similar intrinsics for other
math functions.

Dan

--
Dan Gohman, Cray Inc.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Other Intrinsics?

Chris Lattner
On Tue, 27 Nov 2007, Dan Gohman wrote:

>> > Intrinsics get added on demand.  Generally there has to be a good reason
>> > to add them.  llvm.sin was implemented (for example) to allow generation
>> > of code that uses vector sin operations.
>>
>> What is the criteria for adding an intrinsic or a built-in operation?
>> For example, could the 'frem' instruction be an intrinsic?  Could you
>> remove it from LLVM entirely and make it an external function?  What
>> distinguishes 'frem' from 'sin', 'pow', 'atan2', etc.?
>
> The main difference from my perspective between intrinsics and instructions
> is that intrinsics don't require bitcode format changes. If someone wants an
> atan2 intrinsic for example, it would be fairly easy, and we wouldn't have
> to worry very much about collisions with other people adding new intrinsics,
> where we would if we were adding new operators.

Right, intrinsics trade off easier encoding in the bc format and .ll
files with having less dense encodings and less natural syntax.

However, this begs the question: what is the advantage of instructions
over intrinsics?  Why not get rid of fmod?  If we got rid of fmod, why not
fadd, fdiv, ?

> The main reason for adding intrinsics instead of just using C library
> calls is for support for vector types. @llvm.sin.* can be overloaded as
> @llvm.sin.v4f32, for example, which is very useful for some users.

My question is "how can these be used" by people.  Specifically, these
need to be lowered to some sort of runtime calls (no hardware has support
for these) and llvm doesn't provide a standard runtime yet.  Unless the
codegen has a way to lower these, it seems strange to add them as
intrinsics.  IOW, if llvm.sin.v4f32 ends up being 4 calls to sinf, why not
encode 4 calls to sinf in the bytecode?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Other Intrinsics?

Zack Rusin-3
On Tuesday 27 November 2007 06:01:34 pm Chris Lattner wrote:

> > The main reason for adding intrinsics instead of just using C library
> > calls is for support for vector types. @llvm.sin.* can be overloaded as
> > @llvm.sin.v4f32, for example, which is very useful for some users.
>
> My question is "how can these be used" by people.  Specifically, these
> need to be lowered to some sort of runtime calls (no hardware has support
> for these) and llvm doesn't provide a standard runtime yet.  Unless the
> codegen has a way to lower these, it seems strange to add them as
> intrinsics.  IOW, if llvm.sin.v4f32 ends up being 4 calls to sinf, why not
> encode 4 calls to sinf in the bytecode?

Some of the hardware that we target has extensive support for these. Granted
that instead of overloading llvm.sin and others for my vectors it'd be nicer
to just have llvm.sin that accepts arbitrary vectors but it's still useful.
Of course we could also do regexp matching for multiple sinf's in a row that
operate on the same vector to code-gen something meaningful but with
intrinsics outputting and visually inspecting the IR before feeding it to
code-gen gives one a better idea of what's supposed to happen.

z
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Other Intrinsics?

Chris Lattner
On Wed, 28 Nov 2007, Zack Rusin wrote:
>> intrinsics.  IOW, if llvm.sin.v4f32 ends up being 4 calls to sinf, why not
>> encode 4 calls to sinf in the bytecode?
>
> Some of the hardware that we target has extensive support for these. Granted
> that instead of overloading llvm.sin and others for my vectors it'd be nicer
> to just have llvm.sin that accepts arbitrary vectors but it's still useful.

Ok, if there is hardware with support for it, then I agree it makes sense
to keep them,

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev