[llvm-commits] [llvm] r78379 - in /llvm/trunk: lib/Target/X86/AsmParser/X86AsmParser.cpp test/MC/AsmParser/labels.s test/MC/AsmParser/x86_instructions.s

[Daniel Dunbar]

On Fri, Aug 7, 2009 at 9:50 AM, Chris Lattner<clattner at apple.com> wrote:
> On Aug 7, 2009, at 1:45 AM, Daniel Dunbar wrote:
>
> I'm sure you have a ton of ideas :), but it looks pretty straight-
> forward to break down common conditions into a tree.  Turning the top
> level into a switch on the # operands also looks pretty obvious :).

Yes, I was hoping it was evident I didn't plan on leaving the matcher
like this. :)

I'm tempted to just implement a generic tree match generator; it seems
like there are a number of places we could make use of this. In this
particular case it should allow the tokens and operands to be matched
simultaneously.

I was planning on waiting until the major correctness stuff was done,
though, since it changes the matching a bit. Although I also like
being able to build the code, so... :)

> The generated code looks great for a first cut though!  Maybe it
> should include a comment about the instruction being matched?

Err, lets wait until the matcher is done to optimize this dimension. :)

The only place to put a comment about the instruction is when a
terminal state is reached, at which point the conversion function has
the instruction name already in it. I can add a comment there if you
think it adds clarity.

> Is the code intended to handle regclass constraints yet?  For example,
> in:

Nope. That is the partial order stuff in the comment at the top of
AsmMatcherEmitter.cpp, which isn't implemented yet.

> I don't see how it avoids matching things like "mulss %gs, %eax".  Do
> you intend the matcher to reject this in the future?

Yes, the matcher will reject code which would be ambiguous (and force
the .td user to resolve it), once things are finished. At least thats
my current plan. :)

 - Daniel