similar to: [LLVMdev] LLVM build failure when using CMake

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%

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

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

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]

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

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

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

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

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 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 support automatically :) I agree, that would be

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

I have been working on a LLVM backend for the MicroBlaze (http://en.wikipedia.org/wiki/MicroBlaze ) soft-processor. At this point the backend is partially functional but by no means complete. I was curious as to wether the LLVM developers would prefer to merge the backend into the main tree now and then accept patches on the backend until it was fully functional or if they prefer to wait

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

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

> Ok, the LLVM 2.7 release notes are in near final shape. Please take a look and suggest improvements (or, better yet, just commit improvements if you have commit access): I committed several typo fixes / rewording fixes to the release notes just now. The following paragraph under the "New Useful APIs" section needs to be reworded but I am not sure what is trying to be expressed so

> Would you mind start by adding code to the existing file? Once we have > at least two working architectures we should have a better idea on how > to split it. I can do that. As a note, I just sent another email (before I saw this one) showing how much code was needed to add support for the MBlaze backend. Do you want to take a look at that before I merge the MBlaze stuff into

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 build vs. a > Debug build, lowering the build time for the X86.td rebuild

Attached is a patch that renames ISD::BIT_CONVERT to ISD::BITCAST as per http://www.llvm.org/OpenProjects.html, #3 under Code Generator Improvements. I have not updated the OpenProjects.html file itself as I could not find that file in the source code. The patch itself also includes elimination of whitespace at the end of lines because my VIM settings do that automatically. If this is not desired