[LLVMbugs] [Bug 623] NEW: request for -malloc2alloca optimization pass

[Vikram S. Adve]

Yes, I agree there should be an intraprocedural version that doesn't  
use DSA.  For now, I would be very interested to know how well the  
DSA version works.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/


On Aug 30, 2005, at 10:24 AM, Chris Lattner wrote:

> On Tue, 30 Aug 2005, Vikram S. Adve wrote:
>
>
>> Rob Bocchino has already written such a pass -- perhaps he can  
>> tell you more about how to use it.  It relies on an experimental  
>> pointer and escape analysis called DSA (analyze -tddatastructure)  
>> so please check results carefully.
>>
>
> I asked Eric to file this enhancement request, because (like many  
> gc'd languages) he's seeing a LOT of heap allocations, some of  
> which are very simple to clean up.  The goal of this pass is to do  
> the easy 50% of the cases that doesn't require escape analysis, so  
> it can be very fast.  As an optional second step, something  
> requiring a more heavy-weight analysis (e.g. escape analysis using  
> DSA) could be used.
>
> This is in the same spirit as using things like mem2reg and  
> scalarrepl, which are just light-weight versions of load/store  
> elimination for simple but common cases.
>
> -Chris
>
>
>> Begin forwarded message:
>>
>>
>>> From: bugzilla-daemon at cs.uiuc.edu
>>> Date: August 30, 2005 6:22:38 AM CDT
>>> To: llvmbugs at cs.uiuc.edu
>>> Subject: [LLVMbugs] [Bug 623] NEW: request for -malloc2alloca  
>>> optimization pass
>>> http://llvm.cs.uiuc.edu/bugs/show_bug.cgi?id=623
>>>            Summary: request for -malloc2alloca optimization pass
>>>            Product: tools
>>>            Version: trunk
>>>           Platform: PC
>>>         OS/Version: Linux
>>>             Status: NEW
>>>           Severity: enhancement
>>>           Priority: P2
>>>          Component: opt
>>>         AssignedTo: unassignedbugs at nondot.org
>>>         ReportedBy: eric at vanrietpaap.nl
>>> If such an optimization pass would do escape analysis pypy-llvm  
>>> might be able to
>>> use a lot less malloc. These are currently in pypy-llvm costly  
>>> becausewe use the
>>> Boehm garbage collector that obviously need to do more that a  
>>> normal malloc and
>>> free.
>>> Because the actual Boehm malloc is called GC_malloc this would  
>>> need to be an
>>> alias of malloc. In general it would be nice to be able tell the  
>>> optimizers
>>> about aliases of known functions (could that be useful for  
>>> simplify- libcalls
>>> translations, just guessing here). Or maybe this is already  
>>> possible by
>>> implementing an internal malloc in the .ll file. Not sure here,  
>>> will have to try
>>> that later.
>>> [If part two makes sence then this enhancement request should  
>>> have been split]
>>> ------- You are receiving this mail because: -------
>>> You are on the CC list for the bug, or are watching someone who is.
>>> _______________________________________________
>>> LLVMbugs mailing list
>>> LLVMbugs at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
>>>
>>
>> _______________________________________________
>> LLVMbugs mailing list
>> LLVMbugs at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
>>
>>
>
> -Chris
>
> -- 
> http://nondot.org/sabre/
> http://llvm.org/
>
> _______________________________________________
> LLVMbugs mailing list
> LLVMbugs at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
>