llvm dev - Sep 2010 - [LLVMdev] ARM MC .s status?

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

On Sep 14, 2010, at 11:26 AM, Jason Kim wrote:
> 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
Sounds perfectly reasonable to me. We can always adjust later if need be for
some reason. Looking forward to working with you.
> - I haven't thought about
> how this will interact with generating arch-specific .so's directly
> from LLVM...
Semi off the top of my head, I'd expect the normal code path for that to
still go through the linker rather than being emitted directly. If nothing else,
to resolve any symbols that need to be brought in from static libs.  That said,
in combination with the LTO and perhaps some additional restrictions (no static
symbol dependencies, etc.), I don't see any reason why there couldn't be
a .so emitter.


Regards,
  Jim

> Semi off the top of my head, I'd expect the normal code path for that
to still go through the linker rather than being emitted directly. If nothing
else, to resolve any symbols that need to be brought in from static libs.  That
said, in combination with the LTO and perhaps some additional restrictions (no
static symbol dependencies, etc.), I don't see any reason why there
couldn't be a .so emitter.
That is more or less the idea we were playing with. When producing a
.so for PNaCl, all files going into the library must be bitcode files,
but there can be external .so ELF dependencies. Using gold we should
be able to record the dependencies somewhere and output a combined
bitcode.

A custom translator can then be written that takes the combined
bitcode and the dependencies and produces a .so in one step. Ideally
the dependencies would be encoded in the .bc itself, so we would have
a single file going in for each .so.
>
> Regards,
>  Jim

Cheers,
-- 
Rafael Ávila de Espíndola