similar to: [LLVMdev] The MBlaze backend: can we remove it?

On Tue, Feb 5, 2013 at 3:50 PM, Preston Briggs <preston.briggs at gmail.com>wrote: > 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

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

Hi, I just saw this thread. I work on llvm at Xilinx but I do not work on microblaze. I will check to see if there is any interest here at Xilinx to contribute resources to the maintenance of this backend. Thanks, Jeff On Tue, Feb 5, 2013 at 7:38 PM, Rogelio Serrano <rogelio.serrano at gmail.com>wrote: > > On Feb 6, 2013 4:52 AM, "Chandler Carruth" <chandlerc at

On Tue, Feb 5, 2013 at 12:52 PM, Chandler Carruth <chandlerc at gmail.com>wrote: > 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,

On Feb 6, 2013 4:52 AM, "Chandler Carruth" <chandlerc at gmail.com> wrote: > > 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

I think you should wait until it becomes a problem. Xilink is actively hiring for LLVM people so maybe it will get some use again soon. I get at least one email a day from their head hunters. http://en.wikipedia.org/wiki/MicroBlaze On 02/05/2013 01:02 PM, Chandler Carruth wrote: > > > > On Tue, Feb 5, 2013 at 12:52 PM, Chandler Carruth <chandlerc at gmail.com >

Hi jeff! Any news? On Feb 9, 2013 1:53 AM, "Jeff Fifield" <fifield at mtnhigh.net> wrote: > Hi, > > I just saw this thread. I work on llvm at Xilinx but I do not work on > microblaze. > > I will check to see if there is any interest here at Xilinx to contribute > resources to the maintenance of this backend. > > Thanks, > Jeff > > > > On

On 02/05/2013 03:58 PM, Chandler Carruth wrote: > On Tue, Feb 5, 2013 at 3:50 PM, Preston Briggs <preston.briggs at gmail.com > <mailto:preston.briggs at gmail.com>> wrote: > > 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

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

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

> 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

> 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

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

On 12/14/2010 04:28 PM, Wesley Peck wrote: > 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

On 17 January 2011 10:30, Richard Pennington <rich at pennware.com> wrote: > * It is currently based on a fairly recent version of LLVM/clang: r122956. This is great. I've noticed that you've made some fixes or additions that haven't made it upstream yet, such as the Microblaze parameter fix in rev 2337 (CCed Wesley Peck as he seems to have done a lot of work on the MBlaze

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

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

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,

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