search for: targetasmbackend

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 given machine type. The attached patch does some code refactoring so that a backend can create it's own ELFObje...

...communicate on this. In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? I assume, a MCJITStreamer is needed. And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? What was on your mind on this subject ? Anyone has already begin to work on this ? Olivier. On...

...er support, so that we can have test cases in the 'llvm-mc cat' mode, where it just parses and prints out again. On 0001: - What is hasRelocationAddend? It doesn't seem to be needed to me, and I'm not sure why it would be. If this is a private detail to ELF, it shouldn't go in TargetAsmBackend, but rather be an argument to the object writer constructor. - Feel free to submit a patch to split out ELFX86_{32,64}AsmBackend, if you want me to apply it. Little / obvious patches like that are great ones to get in first, and make subsequent patches easier to read. On 0002: - Looks great, ov...

.... > In your open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? > > I assume, a MCJITStreamer is needed. > And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? > > What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? I'm not sure the best path forward on this, Daniel may have an opinion. The two opt...

..., and not any target specific code. TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic. Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer. Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don't think this would be...

Hi guys, attached are a couple of work in progress patches for ELF support in the MC module. I'm sending this email to gather some general feedback on the code. Applying these patches doesn't get you a fully working llvm-mc that understands ELF; it's just the ground work. I've got a couple more small patches that fixup some places that assume Mach-O object format which I'll

...2010 10:53, Anton Korobeynikov <anton at korobeynikov.info> wrote: > Hello, Nathan > I'll let others comment on MC hooks, I just made a very brief look > over the contents of the archive. You can find the comments below. > Yes I looked at this and there are several ways but TargetAsmBackend looked the bast place to deal with the MCStreamer choice for different TargetTriples. > for (SmallVector<char, Len>::const_iterator i = > Data.begin (); i != Data.end (); i++) > > { > > if (i != Da...

...our open points, you speak about upgrading the JIT code path. If I want to take a look (or at least try...) on it, what would be the "roadmap" ? >> >> I assume, a MCJITStreamer is needed. >> And probably a JITObjectWriter (inherits from MCObjectWriter) and an associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? >> >> What would be the chaining of calls ? The JITObjectWriter::WriteObject is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be created ? > > I'm not sure the best path forward on this, Daniel may have an opi...

...sponsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic. TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho. > Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer. Right, that is the actual implementation of the object writer for a specific target. > Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The...

...o > modify LLVM itself, but my changes main goal was minimal impact on LLVM > sources. > AFAICT The hooks you sent did not call your code at all. Have a look at the MachOWriter, this is designed to be extendable to other writers. The MCStreamer stuff just needs the same doing probably in TargetAsmBackend. It would be good to have this as a separate patch. This will allow both COFFWriter and ELFWriter as well as the MachOWriter to coexist and be selected by TargetTriple. BTW could you have your Writer and Streamer in different source code files, and follow the MachO code format as far as is possible...

...out upgrading the JIT code path. If I > want to take a look (or at least try...) on it, what would be the "roadmap" > ? > >> > >> I assume, a MCJITStreamer is needed. > >> And probably a JITObjectWriter (inherits from MCObjectWriter) and an > associated TargetAsmBackend specific to the JIT (JITX86AsmBackend) ? > >> > >> What would be the chaining of calls ? The JITObjectWriter::WriteObject > is called via the AsmPrinter::doFinalization. But how the AsmPrinter will be > created ? > > > > I'm not sure the best path forward on...

On Apr 9, 2010, at 23:32:12, Chris Lattner wrote: > Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: > http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thanks for the post, Chris. It

Thanks for both of your feedback, I will attempt to make it fit LLVM coding standards better before I resubmit my work. As far as the hooks I put in, they are really only there so I could build the object exporter outside of LLVM, I think having it built directly in like others is preferable in the end. I do think it would be useful if projects had the option of extending supported formats

> 1. What is the preferred method in MC to jump back to a prior section > already defined? (Or is this not supported?) SetSection in the MCStreamer if you really want to change the current section, but maybe all that you need is to setSection in the Symbol? Similar to what is done in MCELFStreamer::EmitCommonSymbol if the binding is local. > 2. It looks like the "correct" way

...ning: comparison between signed and unsigned integer expressions <dir>/llvm/lib/CodeGen/RegAllocGreedy.cpp:382: warning: ‘BestWeight’ may be used uninitialized in this function <dir>/llvm/lib/CodeGen/RegAllocGreedy.cpp:382: note: ‘BestWeight’ was declared here <dir>/llvm/lib/MC/TargetAsmBackend.cpp:34: warning: comparison between signed and unsigned integer expressions =================================================== Garrison

Several people have asked what the MC project is all about, and it is now getting to a point where it is pretty interesting and there are lots of potential projects for people who are interested. I wrote a big post about what it is here: http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html Thoughts and comments welcome, -Chris

...ue.h" > +#include "llvm/MC/MCAssembler.h" > +#include "llvm/MC/MCAsmLayout.h" > #include "llvm/MC/MCCodeEmitter.h" > #include "llvm/MC/MCSectionCOFF.h" > +#include "llvm/Target/TargetRegistry.h" > #include "llvm/Target/TargetAsmBackend.h" > +#include "llvm/ADT/StringMap.h" > + > #include "llvm/Support/COFF.h" > #include "llvm/Support/Debug.h" > #include "llvm/Support/ErrorHandling.h" > #include "llvm/Support/raw_ostream.h" > using namespace llvm; &gt...

On Sun, Jul 11, 2010 at 6:10 PM, Chris Lattner <clattner at apple.com> wrote: > This probably needs to be slightly tweaked to work with mainline.  I don't see anything objectionable, but I think Daniel needs to review this one. Updated patch to work with mainline. http://github.com/Bigcheese/llvm-mirror/commit/d19a4c82c18afc4830c09b70f02d162292231c94 - Michael Spencer

Hello, Nathan First of all, I would like to mention that COFF MC backend will be a really good contribution to LLVM! > I have created a minimally functional Win32 COFF Exporter using the new MC > framework. I made some minor changes to other libraries to allow me to plug > it in without building it as part of the LLVM project. I wanted to share it > but wasn't sure how to go

...d something. This aproach also allows me to keep this code in source control as I bounce between development machines multiple times a day. > Have a look at the MachOWriter, this is designed to be extendable to other > writers. The MCStreamer stuff just needs the same doing probably in > TargetAsmBackend. It would be good to have this as a separate patch. This > will allow both COFFWriter and ELFWriter as well as the MachOWriter to > coexist and be selected by TargetTriple. BTW could you have your Writer and > Streamer in different source code files, and follow the MachO code format as &gt...