[RFC v2] Towards an assembler parser for PowerPC

Kevin Enderby enderby at apple.com
Mon Mar 18 12:08:50 PDT 2013


Hi Ulrich,

One comment below which I previously emailed David on.

Kev

On Mar 18, 2013, at 11:55 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote:

> David Fang <fang at csl.cornell.edu> wrote on 14.03.2013 00:32:56:
> 
>>    Just wanted to ping and ask how close we are to seeing
>> PPCAsmParser.  I've made good progress on the mach-o/PPC backend, but
> have
>> run into a few blocks.
> 
> I've been out sick for the past two weeks and didn't make any progress,
> sorry.  But I'm back working on the asm parser now ...
> 
> One piece of good news is that Jakob has been looking at some of the
> common TableGen changes, and it looks like this is close to getting in.
> 
>> 1) lib/Target/PowerPC/PPCAsmPrinter.cpp:PPCDarwinAsmPrinter emits a
>> bcl instruction in the stub for dynamically linked functions.
>> Would it be easy to MC-ize the bcl (branch-conditional-link) instruction?
> 
> Well, at some point we'll have to add the full set of branch instructions
> anyway to support the complete instruction set in the parser; I've
> considered
> that to be a follow-on step after the first instance of the parser gets
> committed ...
> 
> In any case, adding a new pattern (with isCodeGenOnly = 1) to be
> generated by PPCDarwinAsmPrinter ought to be straightforward for now.
> 
> For my curiosity:
> 
>      OutStreamer.EmitRawText("\tbcl 20, 31, " + Twine(AnonSymbol->getName
> ()));
> 
> bcl 20 ... seems to imply an unconditional branch after all.  Do you
> know why this can't just use a plain bl?

Basically it is a branch and link instruction but causes the processor to not put the return address in the link register stack.  As this is the pic code that is branching to itself to get the pc into a general register.  And thus will never return to that address.

> 
>> 2) Some of the system C++ headers (4.0.1) have inline asm, so I'm unable
>> to compile an <iostream> hello-world using the integrated-assembler.
>> 
>> clang gripes:
>> fatal error: error in backend: Inline asm not supported by this streamer
>> because we don't have an asm parser for this target
>> 
>> (A <stdio.h> version in C works though.)
>> I assume the PPC asm parser will solve this?
> 
> Yes, this should be supported with the asm parser.  (Of course, assuming
> that the particular instructions used in those inline asm statements are
> already supported.)
> 
> Bye,
> Ulrich
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits




More information about the llvm-commits mailing list