[LLVMdev] Marking a function prototype as being "persistent"

[Charllls Alquarra]

on Jan  6, 2011  9:21 pm Christophe de Dinechin wrote:
>On 7 janv. 2011, at 01:00, Duncan Sands wrote:  
>>That said, probably the reason you are getting improved optimization is due to
>>running the "internalize" pass. If so be warned that it is not safe to run
>>internalize unless all functions and their bodies are present in the module. 


>All functions and bodies are present, so that's not the issue. The issue is that
>some inputs of LTO are destroyed as a side effect of running it. 


>>If you run internalize, optimize, and then later add a few more functions to the
>>module all kinds of nasty subtle things can go wrong, not just those you saw
>>with GlobalDCE. 

>Do you mean I should assume for example that the Functions I generated are also
>irreversibly damaged? If so, what passes do I need to avoid if I want to
>preserve the ability to do incremental recompilation?


First of all, Sorry for waking up this zombie thread from jan 2011, but i'm investigating incremental compilation
and i haven't found much else besides this.

As a question to Christophe, but also to anyone that might help; are your functions being
evicted from the final module after LTO *even* if the functions are created with External Linkage?

notice the following points:


1) my understanding is that a function with external linkage should be always available. That is
how libraries export their symbols after all.


2) my understanding also (and this is the crucial point) is that LTO as a optimization phase should
be equally applicable to final executables or libraries. Libraries always should have their 

export/external symbols available even if they seem to not be called from inside the available code.
(libraries would be very useless objects after all!). This does not (or *should not*) preclude
LTO optimization of the library dependencies

am i making sense here?

thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120205/f46d1b42/attachment.html>