similar to: [LLVMdev] Need advise on adding tests - Was: Re: ARM MC .s status?

Is the rationale that llvm has matured/advanced to the point where integration tests are the only ones to make sense from a test density perspective? On Thu, Sep 16, 2010 at 5:05 PM, Jason Kim <jasonwkim at google.com> wrote: > Hi everyone, > > I am trying to get up to speed on the MC object file emission for ARM, > the first cut being for ELF, and the testing required for that.

Hi everyone, Rafael has graciously given me some pointers for helping out on the ARM/MC .s emission infrastructure, and I am volunteering to do so. It looks like as of yesterday, the MC obj emitter for ARM is also incomplete (there does not seem to be a ARMMCCodeEmitter.cpp, for example) So if anyone already has started looking into this, I'd like to pool info so as to not step on toes. Any

Hi Jason, I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better determine a natural breakdown and separation of tasks. Evan and Chris may have suggestions there, too, as I know they're both very interested in getting this stuff fleshed out and

> Also what is the preferred method for MC way of setting out subsection > sizes after the fact? I am guessing I need to use an MCFixup? > How do I get an MCExpr to evaluate a method for the subsection size? > Is there an equivalent use in the places using MCFixup? > Do I need to add a new subclass to MCExpr for doing this? > > JimG, can you please comment on the MachO

Hi Jim! On Tue, Sep 14, 2010 at 11:08 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Jason, > > I've just started actively working on this. Coordinating to get things moving even faster sounds great! Can you elaborate a bit on your ultimate goals and use cases are? That might help us better determine a natural breakdown and separation of tasks. Evan and Chris may have

Hi Everyone, I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, and had some questions. Currently, it defines quite a few methods like printAddrMode4Operand (linked to ARMInstrInfo.td) that currently assume raw text support in the OutStreamer. Are these methods still supposed to be invoked in the MC'ized path for assembly output? Is JimG's new MC/.s

On Sep 29, 2010, at 3:09 PM, Jason Kim wrote: > Hi Everyone, > > I am trying to decide on a MC'ized reorg of ARMAsmPrinter for MC/ELF, > and had some questions. > > Currently, it defines quite a few methods like printAddrMode4Operand > (linked to ARMInstrInfo.td) that currently assume raw text support in > the OutStreamer. Are these methods still supposed to be

2010/10/21 Jason Kim <jasonwkim at google.com>: > That is exactly what I need - I need a nice MC way to output a at > least two different 4 byte size fields after all of the blobs in the > .ARM.attributes are sent out. Hi Jason, If I got it right, you need to write to the attributes section after you have moved out to print the rest of the file. I can't think of an example

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

-llvmcommits On Mon, Jan 10, 2011 at 3:21 PM, Renato Golin <renato.golin at arm.com> wrote: > Btw, I know this is for ELF printing, but can the same infrastructure > you're using to print the hi/lo be used to print relocation in Asm > output? Or is this a completely separate subject? Hi Renato, If I am understanding you correctly, then the answer is no, because .s output

Hi everyone, I am in the process of adding some new code for th ARM/MC ELF emission, but noticed a curious linkage between th AsmPrinter and the MC. It looks like the MC code (on X86 at least) calls out to the (misnamed?) AsmPrinter to dump out ELF bits (in X86AsmPrinter.cpp) in the same routine, using conditional branching.... As JimG and I are working both on ARM emission stuff, I want to

2010/10/21 Jason Kim <jasonwkim at google.com>: > Of the 45 remaining, there are 4 interesting uses in MCAsmStreamer.cpp > - (I suppose for emitting data constants in a cross platform manner) > The other remaining uses are in AsmPrinter, again to do cross platform things. > It seems a bit strange to use a high level hammer to do ballpeen > work..... But when in Rome.... :-)

Hi everyone, while looking at the ARMAsmPrinter::EmitStartofAsm function, I realized that what looks like singular assembler directives (.eabi_attribute) are in fact shorthand that needs to go in to the .ARM.attributes section in the ELF file. 1. What is the preferred method in MC to jump back to a prior section already defined? (Or is this not supported?) 2. It looks like the

On Thu, Oct 21, 2010 at 11:42 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Also what is the preferred method for MC way of setting out subsection >> sizes after the fact? I am guessing I need to use an MCFixup? >> How do I get an MCExpr to evaluate a method for the subsection size? >> Is there an equivalent use in the places using MCFixup? >>

Dear all, AFAIK, ARM EHABI is not ready for both asm and obj emitter. Some people including me what to implement them. My question is, to avoid duplicate effort, does someone take charge of this part? or does anyone is already implementing this currently? BTW, any suggestion on this effort? I'm very appreciated! Thanks in advance! -- Best regards, Wen-Han Gu (Nowar) -------------- next

> Hmm, I wish we had this discussion way earlier.. > > How would I emit things in different subsections? I can do a high > level switch to .ARM.attributes, and if I were emitting one blob from > begin to end, using the higher level interface would be preferable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC

On Thu, Oct 21, 2010 at 7:50 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >> Hmm, I wish we had this discussion way earlier.. >> >> How would I emit things in different subsections? I can do a high >> level switch to .ARM.attributes, and if I were emitting one blob from >> begin to end, using the higher level interface would be preferable,

Hello > My question is, to avoid duplicate effort, > does someone take charge of this part? or > does anyone is already implementing this currently? > > BTW, any suggestion on this effort? I'm very appreciated! There are several directions here: 1. Binary emission. Right now MC layer is text-only and depends on assembler 2. Correctness issues. It's believed that unwinding

Just in case it interests anyone else, I'm playing around with trying to broaden the MCStreamer API to allow for emission of bytes without copying the contents into a local buffer first (either because you already have a buffer, or the bytes are already present in another file, etc) in http://reviews.llvm.org/D17694 . In theory there's some overlap with lld here (no doubt it already does

I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assume that I'm just not doing something necessary for initialization, but I'm not sure what it would be--I am