llvm dev - Nov 2006 - [LLVMdev] LLVM and newlib progress

Chris Lattner kirjoitti:
> There isn't any really good reason to have an llvm intrinsic for write,
> just leave 'write' as an external function.
So is the opportunity for inlining the only reason for e.g. the
llvm.memcpy intrinsic?
-- 
Pertti

On Thu, 9 Nov 2006, Reid Spencer wrote:
>> Currently there are a few intrinsics that have
>> to do with libc, like llvm.memcpy and llvm.memmove. However, I
>> would personally prefer less pollution in the intrinsic name space,
>> so I would propose naming the intrinsics with a llvm.libc prefix,
>> e.g. llvm.libc.open and so forth. Any strong opinions on this?
>
> Yes, it should be completely unnecessary to use intrinsics at all unless
> there is a good optimization reason. The intrinsics we have are either
> lowered generically (e.g. llvm.bswap becomes a series of shifts) or
> lowered by the various targets into appropriate code for that target.
> However, there shouldn't be any reason to implement the system calls
> this way. Again, what issue are you trying to overcome that you think
> intrinsics is the solution?
As a specific example, compiling "printf" to llvm .bc form is very
useful.
However, printf ends up calling "write" at some point, which is a
syscall.
There isn't any really good reason to have an llvm intrinsic for write, 
just leave 'write' as an external function.

-Chris

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

On Thu, 9 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote:
>> There isn't any really good reason to have an llvm intrinsic for
write,
>> just leave 'write' as an external function.
>
> So is the opportunity for inlining the only reason for e.g. the
> llvm.memcpy intrinsic?
No.  llvm.memcpy exists because the intrinsic conveys information the 
libcall doesn't: alignment information.  Other libcalls (e.g. cos) *are* 
inlined, even as direct calls to cos, with no intrinsic.

-Chris

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