llvm dev - Sep 2008 - [LLVMdev] Specifying Additional Compilation Passes to lli

----- "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

----- "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> wrote:
> 
> int power(int (*func)(int), int x, int n) {
>   int i;
>   for (i = 0; i < n; i++) {
>     x = power(x);
>   }
>   return x;
> }
> 
Sorry, the body of the loop should read: x = func(x);
Tom

On Sep 16, 2008, at 12:17 PM, Thomas B. Jablin wrote:
>
> ----- "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.
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
>
>    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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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,
-- 
View this message in context:
http://www.nabble.com/Specifying-Additional-Compilation-Passes-to-lli-tp19440321p20240416.html
Sent from the LLVM - Dev mailing list archive at Nabble.com.