vg_leak issues

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Nov 11 05:05:38 PST 2013


On 11 November 2013 07:53, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
> http://lab.llvm.org:8011/builders/llvm-x86_64-linux-vg_leak
>
> It has a few issues in trunk;
>
> Failing Tests (4):
>     LLVM :: CodeGen/ARM/fast-isel-call.ll
>     LLVM :: CodeGen/ARM/fast-isel-intrinsic.ll
>     LLVM-Unit :: IR/Debug+Asserts/IRTests/IRBuilderTest.RAIIHelpersTest
>     LLVM-Unit :: Linker/Debug+Asserts/LinkerTests/LinkModuleTest.BlockAddress
>
>
> * ARMFastISel
>
> Introduced in r158368 (Chad, Jush).
> +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.

>
> * IRTests/IRBuilderTest.RAIIHelpersTest
>
> MDNode(s), created by MDB, is leaking.
> In IRBuilderTests, getGlobalContext() is used. It is not freed unless
> llvm_shutdown() is called.
> I think it would work if a domestic LLVMContext were used instead of
> the global context.
> (See also MDBuilderTest.cpp)

Should the test call llvm_shutdown maybe?

>
> * LinkerTests/LinkModuleTest.BlockAddress
>
> Excuse me, it has not been reproduced to me.
>
>
> FYI, tblgen leaks many Record(s). I think they might be trivial, since
> tblgen is still a tool.
> Then, suppressing errors with XFAIL:vg_leak might be reasonable here.
> I suppressed 36 tests of llvm/test/TableGen in r194353.

I fixed a few, but there are still many tablegen leaks to fix :-(

Cheers,
Rafael



More information about the llvm-commits mailing list