[llvm] r188188 - Misc enhancements to LTO:

[Shuxin Yang]

>
>>
>> Thirdly, I'm not convinced that lto_codegen_get_files_need_remove 
>> needs to exist. Why not do the file deletion in lto_codegen_dispose?
> You never know long the linker hold the intermediate file.
> On the hand, there was a bug in Apple ld, which never call 
> llto_codegen_dispose.
>
>
>>

I were not clear on this item.

Actually, I try to delete all intermediate files in the 
lto_codegen_dispose(), and I found it is not called on Darwin, which
is a bug. I checked the tool/gold/*, from the code,  I don't know (we 
certainly should not speculate) when the resulting
object files can be safely delete except in the cleanup_hook exposed to 
the linker.

So, it is safe to keep the these files as long as possible (until it is 
deleted by cleanup_hook). Who care disk space?
However, we should delete the LTOCodeGenetator instance as early as 
possible to  free mem space, which is important
as linker is a memory hogging beast.

On Darwin, the intermediate files are deleted after the resulting object 
is brought to memory and hand it over to
linker.  So, it have no problem despite the bug.

In the long run, as I said before. The best place for these damn 
lto_xxxx() APIs is /dev/null...
But for now, in order to move forward, I have to introduce one more API.


   This added API is useful for those:
    - who directly use lto_xxx APIs, and unlike Apple ld, it call 
LTOCodeGenerator::compile_to_file() instead
      of LTOCodeGenerator::compile().
   - and the SW is released independently.  (Hobby project is not a 
concern).

   The user who use gold-linker dose not see this change all, as all the 
change stop at tool/gold/*.cpp which dose not have
to call APIs; they can directly call LTOCodeGenerator::whatever(). 
Darwin users don't worry either, as the files are delete
before the buffer is return back the linker.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130813/0446ac92/attachment.html>