Fwd: [LLVMbugs] [Bug 623] NEW: request for -malloc2alloca optimization pass
Chris Lattner
sabre at nondot.org
Tue Aug 30 08:24:24 PDT 2005
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/
More information about the llvm-bugs
mailing list