Free memory used by initializers of global variables, created during linking

Duncan P. N. Exon Smith dexonsmith at
Fri Jan 16 18:00:18 PST 2015

> On 2015 Jan 14, at 11:58, Manman Ren <mren at> wrote:
>> On Jan 9, 2015, at 3:13 PM, Rafael EspĂ­ndola <rafael.espindola at> wrote:
>>> CAZConstants, CPNConstants and UVConstants are special constants (AggregateZero, PointerNull, UndefValue), it is likely that they will occupy a small amount of space and will be used quite often.
>>> Same arguments apply to IntConstants and FPConstants.
>>> But for completeness, we can include them.
>> Thanks. The main intention is to make sure that any code that calls
>> this while holding a Constant pointer will noticed the problem
>> quickly.
> Done except IntConstants and FPConstants (we currently do not have destroyConstant methods for ConstantInt and ConstantFP).
> It should be easy to add those methods, let me know what you prefer.
>>> InlineAsm is not a subclass of Constant.
>> True. It is a bit odd that it is also uniqued at the Context. We can
>> just skip it.
>>>> * Deleting a constant can cause other constants to become dead. Should
>>>> we iterate until no constants are deleted in a pass?
>>> Theoretically yes, deleting a constant can cause other constants used by it, to be dead.
> Done.
> Updated patch is attached.
> For the application I am working on, ld now runs for 12 minutes with the attached patch; If we do not release memory for ConstantExprs, ld will run for 10 minutes.
> The average # of iterations when releasing memory is 2.7 when we include ConstantExprs. The memory footprint is about the same, peak at 6.4GB.
> One idea is to give finer control over what constant stores to release.
> Thanks,
> Manman

A 20% slowdown seems excessive.  Do I understand correctly that if you
don't delete unused `ConstantExpr`s there's no real slowdown?

Realistically I don't expect `ModuleLinking` to create many surplus
`ConstantExpr`s.  Those referencing `GlobalValue`s from deleted modules
get destroyed when the `GlobalValue`s die, and otherwise most constants
probably get merged in anyway.  I'd prefer to leave that out and avoid
the slowdown.

(I'm tempted even to narrow the scope just to `ConstantArray`s, since the
only quadratic memory explosion is on arrays with appending linkage.)

Rafael, what do you think?

More information about the llvm-commits mailing list