vg_leak issues

[NAKAMURA Takumi]

For now, I suppressed a couple of arm-fast-isel tests with
XFAIL:vg_leak in r195010,
and filed; http://llvm.org/bugs/show_bug.cgi?id=17978

FYI,

>  LLVM-Unit :: IR/Debug+Asserts/IRTests/IRBuilderTest.RAIIHelpersTest

Benjamin did in r194797.

> LLVM-Unit :: Linker/Debug+Asserts/LinkerTests/LinkModuleTest.BlockAddress

It has been removed in trunk. Who can clean up build tree?

2013/11/15 Rafael Espíndola <rafael.espindola at gmail.com>:
> On 14 November 2013 12:39, Tim Northover <t.p.northover at gmail.com> 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.
>
> Cheers,
> Rafael