similar to: [LLVMdev] 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. Tom ----- Original Message ----- From: "Evan Cheng" <evan.cheng at apple.com> To: "LLVM Developers Mailing

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

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:

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

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

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)

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]

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

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

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

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>

What do you think of this patch? I have added a check for the case I mentioned in the previous email as well as a similar situation I discovered later. Tom ----- Original Message ----- From: "Dan Gohman" <gohman at apple.com> To: "Thomas B. Jablin" <tjablin at CS.Princeton.EDU> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent:

Hi, The call target pass in the poolalloc suite yields an incorrect output for the following short test program: #include <stdio.h> struct OP { void (*func)(struct OP*); }; void bar(struct OP *op); void foo(struct OP *op) { printf("Foo\n"); op->func = bar; } void bar(struct OP *op) { printf("Bar\n"); op->func = foo; } int main(int argc, char **argv)

Hi Hisham, Most likely the basic blocks are the headers of two different loops. Try running viewCFG() on the function in question to see if this is the case. Tom ----- Original Message ----- From: "Hisham Chowdhury" <hisham_chow at yahoo.com> To: llvmdev at cs.uiuc.edu Sent: Wednesday, June 16, 2010 7:22:00 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Loopinfo Analysis

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 llc. The reason is that in JITEmitter.cpp only checks to see if CurBufferPtr == BufferEnd at the beginning of the function and not after all

Hello, I have a question regrading the analysis pass that generates loop info from an .ll code. My previous understanding was there will be just one loop header(in the loop info) for a particular loop. But, when i use isLoopHeader() member function from the loop info class I get 'true' return value for two different basic blocks. Note both basic blocks are loop conditional block(break