reset method for WinCOFFObjectWriter

[Yaron Keren]

The PassManager+Passes+MC* were apparently designed for reuse without
reconstructing them every time. Passes reset their state
in doFinalization() and MC* in a reset() function. For
instance, MCAssembler::reset():
...
  // reset objects owned by us
  getBackend().reset();
  getEmitter().reset();
  getWriter().reset();
  getLOHContainer().reset();

If all states are reset correctly, it should be possible to feed different
modules into the same PassManager.

However that is not the way clang or MCJIT work now, they create a
PassManager, use it to produce object or assembler file and kills the
PassManager. This does not sound very time-efficient but I had not measure
the performance impact. I'm trying to keep the PassManager alive for other
reasons.

I don't know if there are other users of PassManager that keep it alive, so
doFinalization() and reset() sufferred code rot with regard to reseting
state. Most are OK but pieces are missing here and threre. Keeping this
existing structure alive will enable reusing the passManager.

Testing could done in a unit test that reuses the PassManager for compiling
several files.

Yaron




2014-09-15 21:47 GMT+03:00 Reid Kleckner <rnk at google.com>:

> Seems obviously correct. Is there a way to test this? Do we just leak
> memory now? If so, why haven't our bots caught it?


On Mon, Sep 15, 2014 at 11:29 AM, Yaron Keren <yaron.keren at gmail.com> wrote:

> This add a reset method for WinCOFFObjectWriter, like other MC* classes.
>
> http://llvm.org/bugs/show_bug.cgi?id=20926
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140915/c73f2878/attachment.html>