Specifying Additional Compilation Passes to lli

> Evan,
> So, if I understand you correctly, the design you have in mind is
> to: create a PassManager, pass it to the JIT on construction, and
> modify runJITOnFunction to run the second PassManager on the
> Function being jit'd before running the codegen PassManager.
Thanks.

Optimiztions should be done before JIT, right? Why not run the
optimizations (using the second PM) on the function that's scheduled

for JIT before? Perhaps I am not understanding what you are trying to

do.

Evan

Evan,
    My goal is to support dynamic optimizations. Typically, a dynamic optimization instruments code at runtime, then when enough profiling information has been gathered the code is recompiled without the instrumentation and with additional optimizations, if appropriate. Sophisticated JITs, like Hotspot, will sometimes compile the same function or code region multiple times in response to profiling information or to specialize code for varying inputs.
    Consider the following example function:

int power(int (*func)(int), int x, int n) {
  int i;
  for (i = 0; i < n; i++) {
    x = power(x);
  }
  return x;
}

    Hotspot can replace the indirect function call with an inlined copy of the called function. This transformation is impossible statically, since function pointed to by the first argument is unknown at compile time. In order to employ similar optimizations in LLVM, passes should be specifiable from the lli command-line. Furthermore, passes need to be able to interrogate the execution engine to find the Function corresponding to a pointer to a given function stub. (I have implemented this as well, and will submit it in my next patch.) Finally, the passes will need utility methods for examining the stack frame of the method being called, and for requested that functions be re-examined at each invocation. In the distant future, OSR (On-Stack Replacement) within the LLVM JIT would be nice too.
Tom

Sorry, the body of the loop should read: x = func(x);
Tom

Evan,
So, if I understand you correctly, the design you have in mind is
to: create a PassManager, pass it to the JIT on construction, and
modify runJITOnFunction to run the second PassManager on the
Function being jit'd before running the codegen PassManager.

Thanks.

Optimiztions should be done before JIT, right? Why not run the
optimizations (using the second PM) on the function that's scheduled

for JIT before? Perhaps I am not understanding what you are trying to

do.

Evan

Evan,
   My goal is to support dynamic optimizations. Typically, a dynamic optimization instruments code at runtime, then when enough profiling information has been gathered the code is recompiled without the instrumentation and with additional optimizations, if appropriate. Sophisticated JITs, like Hotspot, will sometimes compile the same function or code region multiple times in response to profiling information or to specialize code for varying inputs.

Dynamic optimizations are being done by several systems which utilize LLVM JIT. I believe they are use a separate pass manager to control what optimization passes are run at runtime. I'd advise you to do the same. If I understand your requirement correctly, you'd like the JIT to run additional optimization passes when a function is lazily compiled, right? That will require overriding the default JITCompilerFn in JITEmitter.cpp.

You'll also have to roll your own lli replacement. Fortunately that's pretty straight forward.

Evan

Hello:

I am trying to do something similar to what Tom was doing. I want to add a
profiling pass to the entire module before JIT'ing it. I then want to run
the JIT'd functions for a while and then re-JIT them after they have been
executed enough times.

I am currently facing some difficulties. For example, in lli.cpp I added
right after the line that says MP=getBitCodeModuleProvider(Buffer,
&ErrorMsg); :

PassManager PM;

PM.add(new TargetData(Mod));
PM.add(new PrintModulePass());
PM.add(createEdgeProfilerPass());
PM.run(*Mod);

Correct me if I am wrong, but this is what I thought would be the way to
first print the module and then run a edge profiler pass. However, this does
not work, and asserts that Ghostlinkage is not allowed inside the print
module pass. If I comment that out, it gives me some other assert when
running the EdgeProfiler pass.

Can someone point out if I am doing something obviously wrong?

My second question is this: assume that I successfully create a profiler
pass and now the application has been JIT and is running (and incrementing
the edge counters). How do I read these back in a subsequent pass? What I
want to do is ideally wait till 1 second (presumably using a placing a timer
interrupt in lli.cpp), and read back all the counter values and clear all
the JIT's code cache and re-optimize based on profile information. What is
the most direct/efficient way of doing this?

Thanks in advance,