[RFC v2] Towards an assembler parser for PowerPC

[Bill Schmidt]

On Mon, 2013-03-18 at 12:08 -0700, Kevin Enderby wrote:
> 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.

Hi Kevin,

Sorry to poke my nose in, but I wonder whether this is correct.  There's
no documentation in the ISA to indicate this is expected behavior.  I
suppose it's possible that there is a specific hardware implementation
for G5 that I'm not aware of, but from an ISA standpoint "bl" and "bcl
20" are equivalent.

There is support for avoiding polluting the link cache with return
instructions in the bclr[l] and bcctr[l] instructions, by specifying
particular values in the BO field.  But I can't find any reference to
such hints for bcl.  If you have some documentation on this behavior, I
would certainly be interested.

Could you please double-check whether this works as you intend?  If not,
it would be simplest to just replace the bcl with a bl.

Thanks,
Bill

> 
> > 
> >> 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
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>