search for: peckw

On the trunk version of LLVM I am getting the following build error on Snow Leopard (v10.6.2): llvm[3]: Building X86.td DAG instruction selector implementation with tblgen Assertion failed: (LHS->ID != RHS->ID), function operator(), file /Users/peckw/Projects/llvm/llvm-pristine/utils/TableGen/DAGISelEmitter.cpp, line 183. ... <cut - see full_stack_trace.txt> 0. Program arguments: /Users/peckw/Projects/llvm/build/pristine/Debug+Checks/bin/tblgen -I /Users/peckw/Projects/llvm/llvm-pristine/lib/Target/X86 -I /Users/peckw/Projects/llvm/llvm...

...o the main tree now and then accept patches on the backend until it was fully functional or if they prefer to wait on merging the MicroBlaze backend until it was fully functional. If interested, you can view source to the MicroBlaze backend here: http://git.wesleypeck.com/projects/llvm/repos/peckw/trees/master/lib/Target/MicroBlaze -- Wesley Peck CSDL Laboratory University of Kansas

On Fri, Nov 12, 2010 at 6:01 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > Will this poking include converting the JIT to use the MC framework? That is the motivation for me poking at things, yes. > I've added an MC based asm parser, disassembler, and code emitter recently to the MBlaze backend and it would be nice to get JIT sup...

Recently I have been getting a build failure while trying to link lli when performing a cmake based build. The failure is: Undefined symbols: "_LLVMLinkInMCJIT", referenced from: (anonymous namespace)::ForceMCJITLinking::ForceMCJITLinking()in lli.cpp.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [bin/lli] Error 1 I have fixed this with the

Wesley Peck <peckw at wesleypeck.com> writes: [snip] > I have fixed this with the attached patch. It anybody else getting > this error? Should I commit the patch? Yes, please. [snip]

...one has stepped up in the past 5 months, then I don't see an issue with removing it. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Eric Christopher > Sent: Wednesday, July 24, 2013 2:10 PM > To: peckw at wesleypeck.com > Cc: llvmdev at cs.uiuc.edu > Subject: [LLVMdev] Deprecating and removing the MBlaze backend > > Doesn't seem to get a lot of love since most of the commits in the last 3 years > have been maintenance. I guess it doesn't take a whole lot of maintenance &gt...

Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro): make none X86.td X86InstrInfo.cpp real 11.568 217% 76.283 177% 34.435 169% user 7.726 141% 70.659 100% 25.608 116% sys 3.234 111% 3.992 100% 6.438 104% make -j2 none X86.td X86InstrInfo.cpp real 7.7346 145% 43.138 100% 25.77 127% user 7.6072 139% 70.414 100% 26.589 121% sys 3.2492 111% 3.984 100%

Doesn't seem to get a lot of love since most of the commits in the last 3 years have been maintenance. I guess it doesn't take a whole lot of maintenance either, but... cc'ing Wesley since he seems to be the last guy to commit to it. Thoughts? -eric

Hello John. John Criswell <criswell at illinois.edu> writes: [snip] > I did not use CMake but the standard autoconf + Makefile build. > > Not sure if this helps, but here it is, for what it's worth. Very interesting, thanks! CMake introduces more parallelism and it would be great to see how much impact it makes. If you can, please run the cmake build with -j32, just to

Will this poking include converting the JIT to use the MC framework? I've added an MC based asm parser, disassembler, and code emitter recently to the MBlaze backend and it would be nice to get JIT support automatically :) -- Wesley Peck On Nov 12, 2010, at 7:42 PM, Daniel Dunbar wrote: > Hi, > > I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. >

On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > The rest is already in Target, so LGTM :-). Move the > MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from > there. Will do. Again, thank for taking a look at this. -- Wesley Peck University of Kansas SLDG Laboratory

On Fri, Nov 19, 2010 at 12:59 PM, Wesley Peck <peckw at wesleypeck.com> wrote: > On Nov 19, 2010, at 2:05 PM, Rafael Espíndola wrote: > >> The rest is already in Target, so LGTM :-). Move the >> MBlazeELFObjectWriter code to ELFObjectWritter.ccp and lets go from >> there. > > Will do. Again, thank for taking a look at...

For a while now I have noticed that when I build LLVM using CMake on my OS X machine there are two dynamically linked libraries, BugpointPasses and LLVMHello, that are built with the extension ".so" instead of the extension ".dylib". This has been causing four test cases to fail when running "make check". The attached patch modifies add_llvm_loadable_module in the

Wesley Peck <peckw at wesleypeck.com> writes: > Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro): That's a dualcore laptop, isn't it? [snip] > One thing that I noticed (not in this table) was that tablegen is > about 300% faster on my machine when building a Release...

Is it kosher to include vim mode line comments inside of LLVM source files? I would like to do this inside of the MicroBlaze backend to ensure that tabs are expanded into exactly two spaces. I see that right now the following files have these vim mode line comments: include/llvm/ADT/SetVector.h lib/Archive/ArchiveInternals.h lib/Linker/LinkModules.cpp lib/Transforms/IPO/DeadTypeElimination.cpp

On Jan 7, 2011, at 2:36 PM, Venkatraman Govindaraju wrote: > When I run LLC with option "-O0 -march=sparc" on following testcase, > fast register allocator crashes with "UNREACHABLE executed" error. LLC > generates code successfully with other standard register allocators > available. I haven't investigated the Sparc backend specifically but... My guess is

I've been working on ELF object support for the MicroBlaze backend and found that ELFObjectWriter assumes the x86/x86-64 architecture. Attached is a patch that makes the 16-bit e_machine value in the ELF header configurable by the target backend. Right now the target backend simply passes the 16-bit value that it would like to use in the ELF header. I have considered a second approach where

Hello, When I run LLC with option "-O0 -march=sparc" on following testcase, fast register allocator crashes with "UNREACHABLE executed" error. LLC generates code successfully with other standard register allocators available. $ cat call.ll define void @test() nounwind { entry: %0 = tail call i32 (...)* @foo() nounwind tail call void (...)* @bar() nounwind ret void }

On Sep 8, 2011, at 7:47 PM, Chris Lattner wrote: > I don't see the conversion to Git actually happening until someone can clearly demonstrate a win for the open source project. I would think that using git would allow LLVM to setup a system whereby commits are pushed to a special buildbot repository instead of the main repository. If a commit fails to pass the test suite then it would be

Hi, I am starting to poke at the LLVM JIT, which seems to be in need of some TLC. If you are a "sophisticated" JIT user and are using either internal APIs (either by integrating with LLVM, or by other C++ tricks), or are using obscure or poorly documented public APIs (e.g., why is runJITOnFunction exposed?) please make me aware of it! I reserve the right to break anything which