[LLVMdev] The best way to cope with AllocationInst type in old code?

[John Criswell]

On 12/15/10 2:37 AM, Nick Lewycky wrote:
> Hamid 2C wrote:
>> Hi all,
>>
>> I am working on some old code which was compiled against llvm-2.5.
>> Anyway, in some places I, AllocationInst is used (e.g. to ensure the
>> instruction's type). Even in your current documentation
>> (http://llvm.org/docs/ProgrammersManual.html), I found an example that
>> uses this instruction.
>> If I got it correctly, this istruction (AllocationInst) has been
>> removed from llvm instruction set. How can I recode the behavior one
>> can expect from the AllocationInst? Should I check for call
>> instructions to malloc?
> AllocationInst was a superclass of the AllocaInst and MallocInst, the
> latter of which was deleted so AllocationInst was removed.
>
> In LLVM, a lot of code was updated to use the isMalloc() out of
> include/llvm/Analysis/MemoryBuiltins.h, but "isa<AllocaInst>(...) ||
> isMalloc(...)" would be closest to "isa<AllocationInst>(...)".

As a related aside, I've been thinking for awhile that it would be nice 
to have an allocator analysis group.  Each pass in the analysis group 
would recognize the allocators for a particular language or system and 
be able to return useful information for a call to that allocator (e.g., 
given a call to an allocator function, return an LLVM value representing 
the size of the allocation).  The passes could chain like alias analysis 
passes; if one pass doesn't recognize a call instruction as a call to an 
allocator, it can ask another pass if it can identify the call.

My reasoning for this is that each language has its own allocator, and 
some of our LLVM passes (e.g., points-to analysis and memory safety 
instrumentation passes) have to be modified if/when they support new 
languages or new operating systems (e.g., mmap() is essentially an 
allocator).  Abstracting these language/OS specific issues into their 
own analysis group appears to be a good idea.

Writing this pass has been on my back burner for awhile, so I mention it 
in case someone else thinks it's a good idea and wants to tackle it or 
thinks it's a bad idea and wants to tell me why.
:)

-- John T.


> Nick
>
>> I'm new to llvm and I would really appreciate any comment or suggestion.
>>
>> Thanks,
>> Hamid
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev