[LLVMdev] ARM MC .s status?

[Jason Kim]

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