search for: llvm_ptrptr_ti

On Mon, 5 Feb 2007, Dan Gohman wrote: > LLVM knows what all the types of the intrinsic functions are; I thought, > why are users (including llvm-gcc...) required to duplicate all this > information in order to use them? I mean in order to call > getOrInsertFunction to get declarations for them. That is an excellent question! :) In the bad old days, we used to allow intrinsics

On Mon, Feb 05, 2007 at 12:28:56PM -0800, Chris Lattner wrote: > On Mon, 5 Feb 2007, Dan Gohman wrote: > > > LLVM knows what all the types of the intrinsic functions are; I thought, > > why are users (including llvm-gcc...) required to duplicate all this > > information in order to use them? I mean in order to call > > getOrInsertFunction to get declarations for

LLVM knows what all the types of the intrinsic functions are; I thought, why are users (including llvm-gcc...) required to duplicate all this information in order to use them? I mean in order to call getOrInsertFunction to get declarations for them. So I wrote this patch, which allows all this code to be generated automatically. Is this a good approach? Dan -- Dan Gohman, Cray Inc. <djg at

Luke Dalessandro wrote: > Gil, it's really easy to add builtins to the llvm-gcc frontend and have > them auto-magically converted to the llvm intrinsic versions. The main > problem with this is that you end up with a non-standard front end that > you have to somehow distribute to the people who need it. There may be > funny licensing problems, etc... I don't really

As mentioned in an earlier mail, I am working on an LLVM backend for a custom processor based on MIPS. My problem is how to extend LLVM to support some esoteric/non-standard feature of the underlying hardware. I saw in the "Extending LLVM" document, that the easiest / most common way to do this was using an intrinsic function, and examples of the technique abound (all SSE for