similar to: [LLVMdev] MC ELFObjectWriter backend refactoring

> 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

> 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

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

+llvmdev On Fri, Nov 12, 2010 at 7:57 AM, Jim Grosbach <grosbach at apple.com> wrote: > > On Nov 10, 2010, at 9:57 AM, Jason Kim wrote: > >> Refactoring the x86 dependent code from ELFObjectWriter class has >> repercussions among several (conflicting) axes of consideration, >> >> 1. namespace pollution - minimize pollution of the llvm:  namespace >> 2.

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

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

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

Jim, You are correct: MipsSubtarget. For llvm-mc we have a straight MCSubtargetInfo object. For llc we get a MipsSubtarget object which derives from MipsGenSubtargetInfo which derives from TargetSubtargetInfo which derives from MCSubtargetInfo. The patch I hope to send out for review will do this: Add a new data member to MCSubtargetInfo base class. It will be a set of integers that is used or

On Dec 10, 2012, at 1:15 PM, "Carter, Jack" <jcarter at mips.com> wrote: > Here are some examples using the gnu assembler reacting to the same input file with different commandline options. > > These are using the GCC assembler on hello.c > // abi o32, arch mips32r2, relocation model pic+cpic > mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s >

Here are some examples using the gnu assembler reacting to the same input file with different commandline options. These are using the GCC assembler on hello.c // abi o32, arch mips32r2, relocation model pic+cpic mips-linux-gnu-as -mips32r2 -EL -KPIC -o hello_gas.o hello_gas.s e_flags 0x70001007 EF_MIPS_NOREORDER EF_MIPS_PIC EF_MIPS_CPIC E_MIPS_ABI_O32 EF_MIPS_ARCH_32R2 // abi

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,

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

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

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

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