llvm dev - Oct 2004 - [LLVMdev] doc about llvm JIT

On Wed, 6 Oct 2004, Reid Spencer wrote:
> This file (UnixLocalInferiorProcess.cpp) is due for porting and placement
in
> lib/System but I haven't gotten there yet.  If you come up with
something that
> works on MINGW, please let me know.
As you might guess by the name, this file is essentially entirely unix
specific.  The debugger is designed so that multiple backends can be
plugged into it for different purposes: I don't think that
"porting" this
to make it work on win32 would be sufficient in any case.  Can't you just
disable the build of this file on non-unix systems?

-Chris
> Henrik Bach wrote:
>
> > Hi
> >
> > When compiling UnixLocalInferiorProcess.cpp, I get these errors:
> > -----------------------
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:41:22:
> > sys/wait.h: No such file or directory
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:
> > In
> >   member function `void <unnamed>::IP::startChild(llvm::Module*,
const
> >   std::vector<std::string, std::allocator<std::string>
>&, const char*
> > const*)
> >   ':
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:255:
> > error: `
> >   pipe' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:255:
> > error: (Each
> >   undeclared identifier is reported only once for each function it
appears
> >   in.)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:264:
> > error: `
> >   fork' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:
> > In
> >   member function `void <unnamed>::IP::killChild() const':
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:428:
> > error: `
> >   WNOHANG' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:428:
> > error: `
> >   waitpid' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:437:
> > error: `
> >   usleep' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:452:
> > error: `
> >   WIFEXITED' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:453:
> > error: `
> >   WEXITSTATUS' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:454:
> > error: `
> >   WIFSIGNALED' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:455:
> > error: `
> >   WTERMSIG' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:460:
> > error: `
> >   SIGKILL' undeclared (first use this function)
> >
C:/MinGW/msys/local/projects/src/llvm/lib/Debugger/UnixLocalInferiorProcess.cpp:460:
> > error: `
> >   kill' undeclared (first use this function)
> > -----------------------
> >
> > It seems to be unix platform specific. However, I'm compiling this
on
> > MinGW. Shouldn't this be moved to lib/System/platform for every
platform?
> >
> > Any suggestions?
> >
> > ============================================================> >
Henrik Bach
> > Open Source Developer
> >
> > e-mail: henrik_bach_llvm at hotmail.com
> > ============================================================> >
Got Freedom?
> > Software Freedom Day 2004 - 28th of August
> > http://www.softwarefreedomday.org/
> > ============================================================> >
> > _________________________________________________________________
> > Opret en gratis Hotmail-konto  http://www.hotmail.com med udsigt til
250
> > MB lagerkapacitet
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/

Hi,

I am interested in the JIT compiler of llvm, namely, lli. I want to know
more about it, but I found little documentation about it. There are a few
paragraphs about JIT in the CGO paper, a list of options dumped from "lli
--help-hidden", and a short webpage of lli in the website. But many issues
are not clearly described. For example,

1. When JIT is available (-force-interpreter=false), under what condition
the JIT compilation will be applied? (Is it applied to any code that is
executed, or just to hot code like Dynamo?)
2. What algorithms are used to identify hot loop regions and hot paths for
runtime reoptimization?
3. How to relate identified executing native code (of hot loops and
regions) back to original LLVM bytecode?
4. What runtime optimizations are applied in the current version?

Would it be possible to provide a more detailed document? If not
convenient, please give us a brief description of files which are in
charge of these functions. I appreciate your effort and time. Thanks.

Shukang Zhou

On Wed, 6 Oct 2004, Shukang Zhou wrote:
> I am interested in the JIT compiler of llvm, namely, lli. I want to know
> more about it, but I found little documentation about it. There are a few
> paragraphs about JIT in the CGO paper, a list of options dumped from
"lli
> --help-hidden", and a short webpage of lli in the website. But many
issues
> are not clearly described. For example,
Unfortunately there isn't just that describes it.  :(
> 1. When JIT is available (-force-interpreter=false), under what condition
> the JIT compilation will be applied? (Is it applied to any code that is
> executed, or just to hot code like Dynamo?)
When the JIT is available, it is always used. JIT availability depends on
whether we have a code generator for the current target or not: currently
we support X86 and Sparc with the JIT.
> 2. What algorithms are used to identify hot loop regions and hot paths for
> runtime reoptimization?
> 3. How to relate identified executing native code (of hot loops and
> regions) back to original LLVM bytecode?
> 4. What runtime optimizations are applied in the current version?
Currently we do not perform any profile-driven runtime optimizations in
the JIT, though it would not be hard at all to do so (we already have the
profiling framework, it's just a matter of plugging them together).

There is also an internal project, known as the "reoptimizer", which
does
do runtime reoptimization of programs, but others know more about it than
I.
> Would it be possible to provide a more detailed document? If not
> convenient, please give us a brief description of files which are in
> charge of these functions. I appreciate your effort and time. Thanks.
All of the JIT specific code lives in lib/ExecutionEngine/JIT.  The code
shared between it and the interpreter lives in lib/ExecutionEngine.  The
JIT also depends on support from a target-specific code generator, which
live in lib/Target/<architecture>.

-Chris

-- 
http://llvm.org/
http://nondot.org/sabre/