search for: jablin

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) { &g...

...g 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 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> &...

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

...quot; <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. W...

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

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

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

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 Subject: Re: [LLVMdev] Specifying Additional Compilation Passes to lli Hi, Here is the diff for the pod f...

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

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] All CallInsts mayHaveSideEffects This is a known bug: http://llvm.org/bugs/show_bug.cgi?id...

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

...;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: PassArgumentsForLLI.diff Type: text/x-diff Size: 9399 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080911/17a9d219/attachment.diff>

...rn Subject: Re: [LLVMdev] MachineCodeEmitter Patch Thanks. But we need to match the type changes in all the target. e.g. ARMJITInfo.cpp, X86CodeEmitter.cpp. Also in MachineRelocation, e.g. getBB. Could you prepare a patch with all those fixed as well? 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> &...

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

...nheritance. Unless someone else has a better idea, my preference would be compiling with ENABLE_RTTI=1 globally until the entire compiler is ready to go RTTI-free. Alternatively, if anyone knows a safe way to dynamically link RTTI and non-RTTI code, I'd appreciate their expertise. Thanks. Tom Jablin

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

...xout.h with FSF gcc's, I found that type_queue was never used in FSF gcc's version. Does anyone know what DBX_DEBUGGING_INFO and XCOFF_DEBUGGING_INFO signify? I know that gt-dbxout.h is machine generated. Does anyone know where and how this machine generation occurs? Thanks. Tom Thomas Jablin wrote: > Hi, > > I am having some difficulties building llvm on Itanium. My procedure for > building LLVM is: > > cd /liberty/llvm.ia64/llvm-2.1 > ./configure > make ENABLE_OPTIZED=1 > cd /liberty/llvm.ia64/obj > /liberty/llvm.ia64/llvm-gcc4.2-2.1.source/configure &g...

On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > Hi, > > I've figured out a little more. #if defined DBX_DEBUGGING_INFO || > XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, > neither is defined on Intanium. In gt-dbxout.h type_queue's uses are > unguarded and thus are undefined on Itanium. W...

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, I'm interested in specifying...

John Criswell wrote: > Small nitpick: in Instruction.cpp, the comment for insertAfter says > insertBefore and not insertAfter. > :) > > -- John T. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > Thanks for spotting