similar to: [LLVMdev] MicroBlaze Backend

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

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

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]

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 }

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

Chandler brought up removing it back in February but Rogelio Serrano said he could maintain it and Jeff Fifield from Xilinx was supposed to check if someone could help. If no 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

I have been working on a LLVM backend for the MicroBlaze soft-processor: http://www.xilinx.com/tools/microblaze.htm http://en.wikipedia.org/wiki/MicroBlaze Attached is the initial MicroBlaze patch. It does the following: 1. Adds mblaze as a target in configure and configure.ac 2. Adds mblaze specific intrinsics in include/llvm/IntrinsicsMBlaze.td and include/llvm/Intrinsics.td 3. Adds mblaze

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

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%

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:

On Jan 30, 2010, at 6:49 AM, Anton Korobeynikov wrote: >> Your patch looks very clean. Some comments: > Heh, Jakob was faster :) I have taken care of everything Jakob mentioned except the extra test cases. I will get to these as soon as I can. > >> - I think you have some literal tabs in your instruction descriptions. > The tabs can be seen in some other places as well.

On Jan 29, 2010, at 9:42 AM, Wesley Peck wrote: > I have been working on a LLVM backend for the MicroBlaze soft-processor: > http://www.xilinx.com/tools/microblaze.htm > http://en.wikipedia.org/wiki/MicroBlaze Very Cool! > Attached is the initial MicroBlaze patch. It does the following: > 1. Adds mblaze as a target in configure and configure.ac > 2. Adds mblaze specific

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

Hello, i am trying to create a LLVM stack to cross compile c code targeting the xilinx microblaze. I built LLVM configured with target=microblaze however cland doesn't like it. When i try to emit llvm code i get the following error: unknown target triple 'microblaze-unknown-none', please use -triple or -arch How should i configure my LLVM stack and then how should i run the tools

Hi Fivos, LLVM refers to the target as "mblaze" for -target. -Jim On Jun 26, 2012, at 8:42 AM, Fivos <fivosz at gmail.com> wrote: > Hello, > > i am trying to create a LLVM stack to cross compile c code targeting the > xilinx microblaze. > > I built LLVM configured with target=microblaze however cland doesn't > like it. When i try to emit llvm code

conmfigure does not accept mblaze nor mblaze-elf as target. checking target system type... Invalid configuration `mblaze': machine `mblaze' not recognized configure: error: /bin/bash ../../spare/llvm/autoconf/config.sub mblaze failed However with microblaze it proceeds fine. But when i try to use clang i get: clang: error: 'microblaze-unknown-none': unable to pass LLVM bit-code

> Your patch looks very clean. Some comments: Heh, Jakob was faster :) > - I think you have some literal tabs in your instruction descriptions. The tabs can be seen in some other places as well. Also, there is a "mix" of coding conventions in the files. It will be really nice to use only one :) > - Your tests are nice, but you could use some more of them. I would recommend

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 this. Heads up: I just lifted some code

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