similar to: [LLVMdev] VIM mode line comments

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 }

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

The Sparc, Microblaze, and Mips code generators implement branch delay slots. They all seem to exhibit the same bug, which is not surprising since the code is very similar. If I compile code with this snippit: while (n--) *s++ = (char) c; I get this (for the Microblaze): swi r19, r1, 0 add r3, r0, r0 cmp r3, r3, r7 beqid r3,

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

> 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

> 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

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

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

On Dec 14, 2010, at 3:46 PM, Richard Pennington wrote: > Notice that the label $BB0_1 is missing. If I disable filling in the > branch delay slots, I get: Is this with the latest SVN HEAD version of LLVM or some other version? The delay slot filler and many other things have been updated for the Microblaze backend. In particular, the commit r120095 for the MBlaze backend fixed some issues

>> Yes, but who's mainline? Is the plan to have a centralized repo with a mainline branch that everybody pushes to > > This one. > >> , or the a linux style model where some person has an official mainline to which he pulls? > > Not this one. > > This shouldn't be a mysterious concept, our policies are well documented here: >

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): http://llvm.org/docs/ReleaseNotes.html Things still needed are marked with FIXMEs. These include: 1. Clang needs a blurb describing what's new in 2.7. Have the clang folks been doing anything for the last 6 months? 2. I

The MBlaze backend seems to be essentially unmaintained since 2011. The maintainer (Wesley Peck who is BCC'ed) seems to have vanished, and in fact all emails to him are bouncing. I propose to remove the MBlaze backend on Friday if none step forward as a maintainer. Currently, folks are having to keep it up to date when changing shared parts of the backend with no help. -Chandler

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:

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

> 5. I could just add the MBlaze backend specific stuff into ELFObjectWriter > like all of the other backends. > Are their any other opinions on this? I personally prefer all of the MBlaze > backend stuff to be contained inside of lib/Target/MBlaze so that I don't > have to hunt around the LLVM source tree when I'm implementing/fixing the > MBlaze backend. If #5 is

> 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 ELFObjectWriter.c? Lets see: * Constructor. Sure, this (or a factory function) will have to be per target. * RecordRelocation. I also expect this to be truly target

On Jul 23, 2011, at 5:37 AM, FlyLanguage wrote: >>>> After git, mainline will still be the most important branch for >>>> the *project*, >>>> but you will work with quite a few branches on parallel. >>>> >>>> >>>> Who's mainline? :) Be prepared to assign a super-merger, like Linus, >>>> to maintain

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