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

Christophe de Dinechin christophe at taodyne.com
Thu Jan 6 10:08:50 PST 2011


On 6 janv. 2011, at 18:24, Reid Kleckner wrote:

> On Thu, Jan 6, 2011 at 10:06 AM, Duncan Sands <baldrick at free.fr> wrote:
>>> So my question is: what is the correct, officially recommended way to reference runtime functions so that global DCE won't get rid of them? Or am I supposed to re-create the corresponding Function instances for every translation?
>> 
>> There's some kind of disconnect here, so you need to explain more :)
> 
> Presumably since he's using the JIT he's generating more code later
> that uses the runtime functions, which he wants to be marked as
> available.

That's correct. Basically, when my runtime decides to JIT some code, it generates a top-level entry point, all the required functions, and then runs LTO on the result. One reason I want LTO is inlining.


> The disconnect is wanting to apply whole-program/LTO type
> optimizations before you have the whole program.

This is a dynamic language. Part of the program source may be a result of previous evaluations, so there's now way to even know when I have the whole program. That doesn't mean I don't want to inline.


> I think the answer is to not use the standard LTO passes and to create
> your own versions that are careful not to do things like delete types
> and prototypes that you might need later.

But standard passes exist for a reason. I tried the approach you suggest, and since I did it (around 2.5 I guess), I didn't keep up. That cost me something like 20% in performance compared to standard passes.

Now, copy-pasting standard passes code just to remove the passes I don't want... nuf said.

It's actually easier in my case to recreate the prototypes each time. But I wanted to check first if there wasn't an obvious way I had missed to bump the use count of a global value or function to indicate that one of my own classes has a live pointer to it.


Thanks
Christophe



More information about the llvm-dev mailing list