On Sat, 23 Oct 2004, Misha Brukman wrote:> > A possible view of intrinsics could be "operations that don't depend > > on the target architecture, but instead on the language runtime". But > > then wouldn't malloc/free be intrinsics? > > Good question. Due to the amount of pointer/data analysis in LLVM, it > is often necessary to consider memory allocation instructions to see > where memory is allocated and deallocated. As such, the malloc/free > instructions provide that higher-level construct that make it easier to > manipulate memory-operating instructions since that is done so often.This information could be provided by an intrinsic just as well.> Consider: for an llvm.malloc intrinsic, one would have to say something > like this every time we wanted to analyze memory usage: > > if (CallInst *CI = dyn_cast<CallInst>(I)) > if (CI->getCalledFunction()->getName() == "malloc") { > // ... > } > whereas with the malloc instruction raising/lowering pass, you would say > if (MallocInst *MI = dyn_cast<MallocInst>(I)) {Not true at all. Consider the "llvm/IntrinsicInst.h" header, which lets us write stuff like this, today: if (MemCpyInst *MCI = dyn_cast<MemCpyInst>(I)) MCI->getSource() MCI->getLength() ... The one advantage that mallocinst has over using an intrnisic is that instructions can have different return values in various parts of the program (e.g., you can write 'malloc int' instead of '(int*)malloc(4)'). -Chris -- http://llvm.org/ http://nondot.org/sabre/
On Sun, Oct 24, 2004 at 01:17:19AM -0500, Chris Lattner wrote:> The one advantage that mallocinst has over using an intrnisic is that > instructions can have different return values in various parts of the > program (e.g., you can write 'malloc int' instead of > '(int*)malloc(4)').OK, then you could say that the *real* advantage of the malloc/alloca instructions is that it can take a type as an operand (which an intrinsic cannot do) and hence can represent code in a more target-independent manner. Consider malloc(sizeof(long)). That may be 4 on one target, 8 on another, so either you always allocate 8 to be correct (with an intrinsic) or you tie the bytecode to a particular size of long, where as with the instruction, just say 'malloc long'. -- Misha Brukman :: http://misha.brukman.net :: http://llvm.cs.uiuc.edu
On Sun, 24 Oct 2004, Misha Brukman wrote:> On Sun, Oct 24, 2004 at 01:17:19AM -0500, Chris Lattner wrote: > > The one advantage that mallocinst has over using an intrnisic is that > > instructions can have different return values in various parts of the > > program (e.g., you can write 'malloc int' instead of > > '(int*)malloc(4)'). > OK, then you could say that the *real* advantage of the malloc/alloca > instructions is that it can take a type as an operand (which an > intrinsic cannot do) and hence can represent code in a more > target-independent manner. > > Consider malloc(sizeof(long)). That may be 4 on one target, 8 on > another, so either you always allocate 8 to be correct (with an > intrinsic) or you tie the bytecode to a particular size of long, where > as with the instruction, just say 'malloc long'.Yup, exactly. Note that this is *still* syntactic sugar, as you can write 'sizeof' portably in LLVM. The real question is why we give special support for malloc/free, which we don't give to other language runtime allocation functions (e.g. operator new' in C++, new in Java, etc). Going forward, it will be interesting to see how we can generalize support for other allocators, I don't think that there is anything intrinsically hard, but it is something that we eventually want to do. -Chris -- http://llvm.org/ http://nondot.org/sabre/