[llvm-commits] [PATCH] Add malloc call utility functions

Evan Cheng evan.cheng at apple.com
Thu Aug 13 00:42:21 PDT 2009


Hi Victor,

The patch looks very nice and clean. I do have some comments though:

+//===- llvm/Analysis/Malloc.h ---------- Identify malloc calls --*- C+ 
+ -*-===//

I don't like Malloc.h. It seems too much like a system header. Perhaps  
MallocHelper.h? Also, I wonder if it belongs to include/llvm/Analysis.  
If all the utility functions are used within Analysis, perhaps it can  
go into lib/Analysis? Or perhaps under Transform/Util if it's only  
used by the optimizer?

+// 
= 
= 
=---------------------------------------------------------------------- 
===//
+//  malloc Call Utility Functions.
+//
+
+/// IsMalloc - Returns the corresponding CallInst if the instruction  
is a call
+/// to malloc and all its uses are BitCastInst.  This matches the IR  
generated
+/// by CallInst::CreateMalloc().  Since CreateMallocCall() only  
creates calls,
+/// we ignore InvokeInst here.
+CallInst* IsMalloc(Instruction* I);

This seems to be checking a property (all uses are BitCastInst) that's  
not apparent from the function name. Why do we want to check whether  
uses are BitCast's?

+/// GetMallocCall - Returns the malloc call whose result is being bit- 
casted.
+CallInst* llvm::GetMallocCall(BitCastInst* BCI) {
+  if (CallInst* CI = dyn_cast<CallInst>(BCI->getOperand(0))) {
+    assert(IsMalloc(CI) && "GetMallocCall and not malloc call");
+    return CI;
+  }
+
+  return NULL;
+}

Ah, I didn't quite understand this when I looked at the declaration.  
It looks like the caller must know it's either a bitcast from a non- 
call (then it return null) or it's a call to malloc. That seems a bit  
strange. Could it just return null if it's a call, but not to malloc?  
This seems like a local utility routine that belongs in a .cpp file  
rather than being made available globally. It performs a very narrow  
and specialized function.

+void llvm::ReplaceAndEraseMalloc(CallInst* CI, Value* newVal) {
+  for (Value::use_iterator UI = CI->use_begin(), E = CI->use_end();  
UI != E; ) {
+    Instruction* I = cast<Instruction>(*UI++);
+    I->replaceAllUsesWith(newVal);
+    RecursivelyDeleteTriviallyDeadInstructions(I);
+  }
+}

The function name indicates it's specific to malloc but it's  
applicable to any call instruction, right? Do we really need it? It  
seems we might have existing routine that does this already?

+/// EraseMalloc - For all uses of the malloc call (which should all be
+/// BitCastInsts), recursively delete all of the dead malloc  
instructions (all
+/// the bitcasts, the malloc call, and the instructions that computed  
the
+/// malloc's size argument).  This function is defined in Local.cpp  
because it
+/// uses llvm::RecursivelyDeleteTriviallyDeadInstructions().
+void llvm::EraseMalloc(CallInst* CI) {

Same concern. If we do need this, then it needs to at least assert if  
the call isn't to malloc. Do you have subsequent patch that uses this?  
Can it become a local function?

Thanks,

Evan

On Aug 11, 2009, at 7:31 PM, Victor Hernandez wrote:

> I am working on fixing the MallocInst/i64 alloca bug:
> http://llvm.org/bugs/show_bug.cgi?id=715
>
> Here is the first of a series of patches that will result in tearing  
> out MallocInst.  Before I can tear it out, I need to update all of  
> the optimization passes and transforms that operate on MallocInst to  
> operate on malloc CallInst instead.
>
> This patch consists of a set of utility functions that create IR for  
> malloc calls and identify that IR.  It also rewrites  
> LowerAllocations to use the new utility function,  
> CallInst::CreateMalloc().
>
> <mallocUtils.diff>
>
> Victor
>
> ---
> Victor Hernandez          vhernandez at apple.com
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list