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 add'l tips and pointers would be greatly appreciated. Thanks! -jasonkim On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at google.com> wrote:> On 13 September 2010 17:36, Jason Kim <jasonwkim at google.com> wrote: >> Hi Rafael, hope things are well. >> >> Sehr suggested I ping you briefly on suggestions/ideas/steps for >> contributing to the MC/ARM code base - >> Any hints/breadcrumbs would be greatly appreciated. > > Sure. CCing nacl-eng in case there are others interested too. > > In the case of ARM the problem is that the assembly printer is still > just that, it prints assembly. It has to be ported to the MC > infrastructure that allows different file formats to be supported. > > There is already a very basic ARM printer that uses MC. It is enabled > by the option enable-arm-mcinst-printer. The task is basically to > complete it. > > I would suggest turning that option on by default and checking what > brakes during "make check-lit" for example. Aborts should be > particular good in pointing out missing features. > >> Thanks! >> >> -jason >> > > Cheers, > -- > Rafael Ávila de Espíndola >
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 working properly. My current high level plan is something like the following: 1. MC-ized Assembly Printer a. Work through the "make check" failures using the MC inst printer. Some of these are false failures due to mnemonic choice differences, but most are real failures. b. Repeat (a) except running the full nightly regression suite, not just "make check." c. Clean up the printer and instruction lowering code to make much less use of the "Modifier" string (which causes lots of tight coupling between the instruction selection code and the asm printer). d. Nuke the old asm printer once the above is complete and enable the MC printer as the One True Printer(tm). 2. Object File Emission a. Add basic infrastructure for the object file emitter. i.e. just construct the classes needed and put in lots of asserts() and FIXMEs. b. Add ARM-specific object file format bits. c. Run through the test suite using the object file emitter, disassembling the output and comparing it to what comes out from the .s->assembler->disassembler execution path. Crush all differences. 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one. a. Hand-wavey stuff. I haven't thought much about this bit yet except in broad terms. b. More hand waving. 4. ??? 5. Profit. -Jim On Sep 14, 2010, at 10:02 AM, Jason Kim wrote:> 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 add'l tips and pointers would be greatly appreciated. > > Thanks! > -jasonkim > > > On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at google.com> wrote: >> On 13 September 2010 17:36, Jason Kim <jasonwkim at google.com> wrote: >>> Hi Rafael, hope things are well. >>> >>> Sehr suggested I ping you briefly on suggestions/ideas/steps for >>> contributing to the MC/ARM code base - >>> Any hints/breadcrumbs would be greatly appreciated. >> >> Sure. CCing nacl-eng in case there are others interested too. >> >> In the case of ARM the problem is that the assembly printer is still >> just that, it prints assembly. It has to be ported to the MC >> infrastructure that allows different file formats to be supported. >> >> There is already a very basic ARM printer that uses MC. It is enabled >> by the option enable-arm-mcinst-printer. The task is basically to >> complete it. >> >> I would suggest turning that option on by default and checking what >> brakes during "make check-lit" for example. Aborts should be >> particular good in pointing out missing features. >> >>> Thanks! >>> >>> -jason >>> >> >> Cheers, >> -- >> Rafael Ávila de Espíndola >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 suggestions there, too, as I know they're both very interested in getting this stuff fleshed out and working properly.It looks like the MC obj emission and MC .s emission are two naturally related, but separate tasks. I think the overall goal of having the MC .s/.o drive the entire flow is probably a great idea. Your plan for MC.s and MC.o sounds spot on as well. I humbly suggest you tackle the .s emission, and I tackle the .o emission - I haven't thought about how this will interact with generating arch-specific .so's directly from LLVM... (I am sure there's a blog post about it somewhere on llvm.org :)> My current high level plan is something like the following: > > 1. MC-ized Assembly Printer > a. Work through the "make check" failures using the MC inst printer. Some of these are false failures due to mnemonic choice differences, but most are real failures. > b. Repeat (a) except running the full nightly regression suite, not just "make check." > c. Clean up the printer and instruction lowering code to make much less use of the "Modifier" string (which causes lots of tight coupling between the instruction selection code and the asm printer). > d. Nuke the old asm printer once the above is complete and enable the MC printer as the One True Printer(tm).> 2. Object File Emission > a. Add basic infrastructure for the object file emitter. i.e. just construct the classes needed and put in lots of asserts() and FIXMEs. > b. Add ARM-specific object file format bits. > c. Run through the test suite using the object file emitter, disassembling the output and comparing it to what comes out from the .s->assembler->disassembler execution path. Crush all differences. > > 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one. > a. Hand-wavey stuff. I haven't thought much about this bit yet except in broad terms. > b. More hand waving.Lots of handwavy stuff - fast incremental feedback based optimization <blah>> 4. ??? > > 5. Profit. > > -Jim > > On Sep 14, 2010, at 10:02 AM, Jason Kim wrote: > >> 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 add'l tips and pointers would be greatly appreciated. >> >> Thanks! >> -jasonkim >> >> >> On Mon, Sep 13, 2010 at 3:06 PM, Rafael Espindola <espindola at google.com> wrote: >>> On 13 September 2010 17:36, Jason Kim <jasonwkim at google.com> wrote: >>>> Hi Rafael, hope things are well. >>>> >>>> Sehr suggested I ping you briefly on suggestions/ideas/steps for >>>> contributing to the MC/ARM code base - >>>> Any hints/breadcrumbs would be greatly appreciated. >>> >>> Sure. CCing nacl-eng in case there are others interested too. >>> >>> In the case of ARM the problem is that the assembly printer is still >>> just that, it prints assembly. It has to be ported to the MC >>> infrastructure that allows different file formats to be supported. >>> >>> There is already a very basic ARM printer that uses MC. It is enabled >>> by the option enable-arm-mcinst-printer. The task is basically to >>> complete it. >>> >>> I would suggest turning that option on by default and checking what >>> brakes during "make check-lit" for example. Aborts should be >>> particular good in pointing out missing features. >>> >>>> Thanks! >>>> >>>> -jason >>>> >>> >>> Cheers, >>> -- >>> Rafael Ávila de Espíndola >>> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >
Hi Jason, Jim, Rafael, We had plans to work on ARM MC (asm and elf), good to see there is an interest, and we'd be glad to help. The ARM part of MC is almost empty, so there's a lot of work in there, probably even before writing the assembly/ELF writers. Also, AFAIK, there is no ELF writer for MC, so wouldn't be good to write one specific for the ARM platform, but keep things generic as much as possible. As I got it, MC is generic and the file writers only get the instructions and sections and "print" them to file. Does it mean MC already have all the section, relocation, attributes, properties that both ASM and ELF have? If that's so, even though they're separate projects (as Jason pointed out), a higher degree of communication will be required to synchronize the MC part. Also, we want to make sure that the generated ASM/ELF is not only GNU compatible, but ARM ABI too (if the user require, in the target triple). We have done some changes to the ISelLowering to conform to EABI, a patch is on its way. Is it correct to assume that, if the user chooses a triple with "eabi-none", we can generate ARM EABI (including RT-ABI intrinsics) code?> 1. MC-ized Assembly PrinterWould be good to make it generic enough, so we could (hypothetically) add ARM assembly as a choice. But that could come as a great weight in the first draft, so I won't be so sad if we can't get it straight away. ;) Irrespective of the asm syntax, we need better support for build attributes, relocation information, stack unwinding, exception tables, etc. That alone should prove a good challenge. In the meantime, we have worked on support for some of these things (build attr, reloc.) for the old writer. I'm preparing some of them as patches and will send soon.> 2. Object File EmissionThat will also need support for features mentioned above, and also in the disassembler. GCC ignores most of the build attributes and "guess" everything else from cpu, fpu and the instructions used. This is far from ideal and we shouldn't follow the same route. If we need to guess anything, lets do it in MC, so when you print assembly, the user can later edit if they so want to (or pass the correct cmd-line options to create them right in the first place). The disassembler should also understand that and *always* give preference to user attributes. Because ASM and ELF writers will use MC, we need explicit relocation information in MC, so the writer can print it correctly to the file. I saw that the Dwarf printer has this working, but the old ARM AsmWriter doesn't (I sent a patch for this a while ago). Maybe we can join them all in MC this time.> 3. JIT. Same basic approach as (1) to replace the current object code emitter with an MC based one.We're not overly concerned about JIT at the moment, but it's good to keep in mind that we also have that route. I would as far as to suggest to create a third data section in the IR, after "target-data-layout" and "target-triple", maybe called "target-info" or "target-options". It could be a target dependent string, but would be best if it was shared among architectures, so you could run IR generated to ARM in an 32bit x86, for instance. We could also pass target specific features (such as build attributes), how to handle unions and ByVal parameters, and maybe some optimization assumptions when generating IR. That would allow the codegen phase to detect not only what was generated, but why, and make the appropriate changes if the execution target does not conform to the intended target's specifications. That is very liberating for JIT environments, but I do realise this is extremely complex. I'd be happy to have just the build attributes on it for now, though. ;) cheers, --renato