search for: neverinline

...so that there is a well-known entry-point to the function. If the function isn't inlined, but arguments are deleted, this capability breaks. As a specific proposal to provide "never inline" in a way that is low-impact on LLVM and solves #3, I suggest that we add a new llvm.neverinline global array variable (like the llvm.used global). This global would point to all neverinline functions, and would have appending linkage (like llvm.used). With this design, these functions would be assumed to be used externally (because a global with external visibility points to them) so no...

Hi Alastair, > Forgive my confusion, but I can't help notice that LangRef states: > > Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be

...is on purpose. But you can use both __attribute__((noinline)) and > __attribute__((used)) for disabling IPO. Fair enough. >> As a specific proposal to provide "never inline" in a way that is >> low-impact on LLVM and solves #3, I suggest that we add a new >> llvm.neverinline global array variable (like the llvm.used global). This >> global would point to all neverinline functions, and would have appending >> linkage (like llvm.used). > > This is an implementation issue, but I wonder if we should use too many of > those "magic" arrays...

Hi Duncan- Forgive my confusion, but I can't help notice that LangRef states: Globals with "linkonce" linkage are merged with other globals of the same name when linkage occurs. This is typically used to implement inline functions, templates, or other code which must be generated in each translation unit that uses it. Unreferenced linkonce globals are allowed to be discarded. Why

Good evening, Kenneth. Thank you to apply (and rewrite my naive code better) and to file the issue to http://llvm.org/bugs/show_bug.cgi?id=7304 I have checked r105528 at this morning. I think the pass must be still cleaned up and rewritten. There are my two proposals for enhancement. 1) To separate Specialization(and rewriting callsites) to other module. It would be better if new module were