[LLVMdev] Specifying Additional Compilation Passes to lli

Thomas B. Jablin tjablin at CS.Princeton.EDU
Tue Sep 16 12:17:42 PDT 2008


----- "Evan Cheng" <evan.cheng at apple.com> wrote:

> On Sep 16, 2008, at 8:44 AM, Thomas B. Jablin wrote:
> 
> > 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

>
> >
> > Tom
> >
> > ----- Original Message -----
> > From: "Evan Cheng" <evan.cheng at apple.com>
> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> > Sent: Tuesday, September 16, 2008 2:38:30 AM GMT -05:00 US/Canada  
> > Eastern
> > Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to
> lli
> >
> >
> > On Sep 15, 2008, at 9:56 AM, Thomas B. Jablin wrote:
> >
> >> Evan,
> >> My overall goal is to support dynamic optimization in LLVM.  In
> >> order to do so, I must gather profiling information at runtime,
> then
> >> recompile the profiled functions. Currently, I'm just adding and
> >> removing calls into my profiler in a custom pass.  What is the
> >> advantage of giving the JIT a second profile manager over my
> current
> >> implementation? Thanks.
> >> Tom
> >
> > It's just a cleaner design. There are well defined pass manager,
> > executionengine, and JIT api's. We don't want to unnecessarily
> extend
> > them. JITState PM controls the codegen passes. If you want to add
> LLVM
> > level optimization passes, you can simple use a separate PM to run 
> 
> > them.
> >
> > Evan
> >
> >>
> >>
> >> ----- Original Message -----
> >> From: "Evan Cheng" <evan.cheng at apple.com>
> >> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>
> >> Sent: Monday, September 15, 2008 12:46:16 PM GMT -05:00 US/Canada
> >> Eastern
> >> Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to 
> 
> >> lli
> >>
> >> Hi Tom,
> >>
> >> I don't think this is the right approach. May I ask you what
> passes
> >> you are trying to add? If you just want to run a number of llvm
> level
> >> optimization passes, the right approach is to add your own pass
> >> manager instead.
> >>
> >> Evan
> >>
> >> On Sep 11, 2008, at 10:30 AM, Thomas B. Jablin wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm interested in specifying some additional passes to the JIT
> via
> >>> the command-line. The enclosed patch allows lli to take compiler
> >>> passes as command-line arguments in the same way opt does. This
> is
> >>> my first submission, so any comments, criticisms, or observations
> >>> would be very welcome. Thanks.
> >>>
> >>> Tom
> >>> Jablin
> >>> <
> >>> PassArgumentsForLLI
> >>> .diff>_______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



More information about the llvm-dev mailing list