[LLVMdev] 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/