[llvm-commits] [RFC] Towards an assembler parser for PowerPC

[Ulrich Weigand]

Hal Finkel <hfinkel at anl.gov> wrote on 18.01.2013 18:52:29:

> > - diff-llvm-asm-branch:  This patch cleans up the other branch
> > patterns.
> > Note that at this point, support for branch conditions is still
> > missing; I
> > need to investigate how to best model this.  (One way might be for
> > the
> > compiler to always generate the primary memnoics BC, and support the
> > large
> > variety of extended mnemonics only via the alias mechanism in the
> > parser ...   Thoughts?)
>
> Can't you just mark the other definitions as CodeGenOnly? It is nice
> to have the aliased memnoics in the assembly output -- it makes
> things more readable (IMHO).

Agreed, when generating .s this should still use mnemonics.  One way
might be to do it in PPCInstPrinter::printInst as is done e.g. for "mr".


> > - diff-llvm-asm-preinc:  This is really a continuation of the
> > previous
> > patch, but broken out due to its size.  All the "store-with-update"
> > patterns are currently encoded using two separate operands for
> > address base
> > and offset, instead of a single memory (memri/memrr) operand.  This
> > confuses the assembler parser, since it tries to parse memory
> > operands in
> > the same way for all instructions.
>
> It sounds like this is what needs to be changed. Are there any major
> impediments to making the parser handle these in a different way?

Well, again the problem is that the parser *first* handles operands
(without even knowing what the instruction is).  So if we parse an
input string like "16(1)", the parser can either generate one complex
operand, or two simple operands.  What's difficult is generating the
one form for some instructions, and the other for others ...

So I'd really prefer for *all* patterns that use a reg+disp type
memory operand to encode it in the *same* way.


> As I mentioned on IRC (and I understand that this would be a pain to
> try), my suggestion is to eliminate the 32-bit patterns (and then
> rename the 64-bit patterns). So long as we don't add i64 to any
> register class in PPCISelLowering in 32-bit mode, then 64-bit ops
> should still be split during legalization (I think?). We might need
> to add a bunch of Pat<> definitions to match the 32-bit operand
> cases. Does anyone know of a reason why this would not work?

I haven't really looked into this yet.  If this works, it would
certainly be preferable to having duplicated patterns ...

Bye,
Ulrich