vg_leak issues

Rafael EspĂ­ndola rafael.espindola at
Thu Nov 14 09:51:53 PST 2013

On 14 November 2013 12:39, Tim Northover <t.p.northover at> wrote:
>>> +unsigned ARMFastISel::getLibcallReg(const Twine &Name) {
>>> +  GlobalValue *GV = new GlobalVariable(Type::getInt32Ty(*Context), false,
>>> +                                       GlobalValue::ExternalLinkage, 0, Name);
>>> +  return ARMMaterializeGV(GV, TLI.getValueType(GV->getType()));
>>>  }
>>> GV leaks.
>> This is a particularly nasty one. During codegen the IR module is
>> constant, so we cannot add to it. It looks like what is needed is for
>> MI to have a way to represent a variable without creating an IR level
>> one.
> Isn't that what ExternalSymbol is for? Though dealing with both of
> those cases is rather annoying, you frequently have to duplicate code
> because a global is almost, but not quite, identical to an external.

That might be one of these cases. Maybe all that is needed is for
ARMMaterializeGV to extract the information it needs (thread local,
indirect, etc) and call a lower level function that takes bools and a
name. This code path can then use the lower level one and avoid
allocating a new GV.


More information about the llvm-commits mailing list