[LLVMdev] Some question on LLVM design
Chris Lattner
sabre at nondot.org
Sat Oct 23 23:17:19 PDT 2004
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/
More information about the llvm-dev
mailing list