similar to: [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

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 ----- Original Message -----

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

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 -------------- next part -------------- A non-text attachment was scrubbed... Name:

Hi, Is this the right mailing list for sending in diffs by irregular contributers? Should I send diffs directly to the code owner instead? Tom ----- Original Message ----- From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, September 11, 2008 1:55:09 PM GMT -05:00 US/Canada Eastern

Hi, Here is the diff for the pod file that goes with my earlier change. Tom ----- Original Message ----- From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, September 11, 2008 1:30:24 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Specifying Additional Compilation Passes to lli Hi,

Thanks. I do not have commit privilege. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, December 8, 2008 5:39:33 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Looks good. Do you have commit privilege? Evan On Nov 22, 2008, at

Looks good. Do you have commit privilege? Evan On Nov 22, 2008, at 1:19 PM, Thomas Jablin wrote: > Here is the corrected version. > > Thomas Jablin wrote: >> Actually, there is a problem with the patch. Please delay review. >> >> Thomas Jablin wrote: >> >>> Hi, >>> The following code: >>> >>> #include<stdio.h>

Here is the corrected version. Thomas Jablin wrote: > Actually, there is a problem with the patch. Please delay review. > > Thomas Jablin wrote: > >> Hi, >> The following code: >> >> #include<stdio.h> >> >> char bigArray[0x1000000]; >> >> int main(int argc, char **argv) { >> printf("mem: 0x%x\n", (unsigned)

Sorry. Here is the correct version. ----- Original Message ----- From: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Friday, December 5, 2008 1:08:57 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev] MachineCodeEmitter Patch Evan, Here are the modifications you asked for. I have, for the

Evan, Here are the modifications you asked for. I have, for the most part, not changed intptr_t to uintptr_t inside the JITInfo classes, because the pointer arithmetic there can sometimes legitimately yield negative numbers. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>

Does any real code benefit from dead code eliminating read-only functions? Tom ----- Original Message ----- From: "Reid Kleckner" <rnk at mit.edu> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Monday, May 10, 2010 9:38:47 PM GMT -05:00 US/Canada Eastern Subject: Re: [LLVMdev]

Actually, there is a problem with the patch. Please delay review. Thomas Jablin wrote: > Hi, > The following code: > > #include<stdio.h> > > char bigArray[0x1000000]; > > int main(int argc, char **argv) { > printf("mem: 0x%x\n", (unsigned) bigArray); > return 0; > } > > causes lli to silently fail, even though it compiles correctly with

Sorry i really forgot to mention one thing. I downloaded the X86 binaries of llvm+clang and llvm-gcc from llvm download site. i hope that is not a debug build. Prasanth J On Sun, Nov 15, 2009 at 1:22 PM, Prasanth J <j.prasanth.j at gmail.com> wrote: > Hi all, > > LLVM is built without debug enabled. Also i am not forcing lli to use > interpreter mode. so i dont think the

I've filed PR3043 for this. Evan On Nov 3, 2008, at 4:00 PM, Prakash Prabhu wrote: > Hi Evan, > > Thanks for the pointers. We found a simple test case that causes the > problem (thanks to Tom in my group): > > #include<stdio.h> > #include<stdlib.h> > > void test(); > void (*funcPtr)(); > > int main(int argc, char **argv) { > funcPtr =

Hi, I saw that Nick Lewycky removed the LLVM portable hash_map and hash_sets. My research group was relying on those classes. What replaces hash_map and hash_set? The LLVM implementation was very convenient as there is no equivalent in STL, and Microsoft's implementation had a different name, as does the C++ 0X implementation. Thanks. Tom Jablin

He is probably using the interpreter on a debug build. Evan On Nov 14, 2009, at 1:40 PM, Eric Christopher <echristo at apple.com> wrote: >> >> for -O3 results refer attachment. >> time clang (- >> O0) llvm-gcc(-O0) >> gcc(-O0) >> real >> 0m10.247s

Hi all, LLVM is built without debug enabled. Also i am not forcing lli to use interpreter mode. so i dont think the reason is not because of debug build or interpreter mode. *step 1: * compiled the 3 files (generic_replica.c ,xacc.c and dacc.c) with clang-cc to llvm bytecode files using -emit-llvm-bc and (-O0/-O3) options *step 2:* bytecode obtained from step 1 (generic_replica.bc, xacc.bc and

On Thu, Sep 25, 2008 at 5:04 PM, Thomas B. Jablin <tjablin at cs.princeton.edu> wrote: > Hi, > The call target pass in the poolalloc suite yields an incorrect output for the following short test program: The DSA results are now (r56847) correct for this test case. The call is marked incomplete. Doing better is actually a pathological case in DSA which is hard to fix without

Hi Evan, Thanks for the pointers. We found a simple test case that causes the problem (thanks to Tom in my group): #include<stdio.h> #include<stdlib.h> void test(); void (*funcPtr)(); int main(int argc, char **argv) { funcPtr = test; test(); } void test() { if(funcPtr == test) { printf("OK!\n"); } else { fprintf(stderr, "Bad!\n"); exit(1);