Tablegen lexer misreading cmp${cc}pd ?

[Quuxplusone]

Bugzilla Link	PR6219
Status	RESOLVED FIXED
Importance	P normal
Reported by	Duncan Sands (baldrick@free.fr)
Reported on	2010-02-03 07:13:45 -0800
Last modified on	2010-02-10 02:36:34 -0800
Version	unspecified
Hardware	PC Linux
CC	clattner@nondot.org, llvm-bugs@lists.llvm.org, scallanan@apple.com
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also

Recently tblgen started throwing (and catching) an exception internally during
the LLVM build.  It doesn't like this snippet from X86InstrSSE.td:

  def CMPPDrmi : PDIi8<0xC2, MRMSrcMem,
                  (outs VR128:$dst), (ins VR128:$src1, f128mem:$src, SSECC:$cc),
                  "cmp${cc}pd\t{$src, $dst|$dst, $src}",
                  [(set VR128:$dst, (int_x86_sse2_cmp_pd VR128:$src1,

The exception is thrown in getOperandNamed with the message:
  Instruction 'CMPPDrmi' does not have an operand named '$ccpd'!
It looks like ${cc}pd is being wrongly parsed as ccpd.

[Quuxplusone]

How do I reproduce this problem?

[Quuxplusone]

Sorry - I completely forgot to explain how to reproduce this!  It occurs
when tblgen is processing X86.td during the build.  Here's how I can
reproduce it (... represents the path to the LLVM objects or source
directory):

gdb --args .../Debug/bin/tblgen -I .../lib/Target/X86 -I .../include -I
.../include -I .../lib/Target -gen-enhanced-disassembly-info -
o.../lib/Target/X86/Debug/X86GenEDInfo.inc.tmp .../lib/Target/X86/X86.td
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program:
/home/duncan/LLVM/llvm.top/dragonegg/solved/llvm/O/Debug/bin/tblgen -I
/home/duncan/LLVM/llvm.top/llvm/lib/Target/X86 -I
/home/duncan/LLVM/llvm.top/llvm/include -I
/home/duncan/LLVM/llvm.top/llvm/include -I
/home/duncan/LLVM/llvm.top/llvm/lib/Target -gen-enhanced-disassembly-info -o
/home/duncan/LLVM/llvm.top/dragonegg/solved/llvm/O/lib/Target/X86/Debug/X86GenEDInfo.inc.tmp
/home/duncan/LLVM/llvm.top/llvm/lib/Target/X86/X86.td
Catchpoint 1 (exception thrown), 0x00007ffff79901e0 in __cxa_throw () from
/usr/lib/libstdc++.so.6
(gdb) bt
#0  0x00007ffff79901e0 in __cxa_throw () from /usr/lib/libstdc++.so.6
#1  0x000000000048d48e in llvm::CodeGenInstruction::getOperandNamed(std::string
const&) const ()
#2  0x00000000004cfa71 in getOperandIndex(std::string const&, std::string
const&, llvm::CodeGenInstruction const&) ()
#3  0x00000000004d0b81 in populateOperandOrder((anonymous
namespace)::CompoundConstantEmitter*, std::string const&,
llvm::CodeGenInstruction const&) ()
#4  0x00000000004d36bd in populateInstInfo((anonymous
namespace)::CompoundConstantEmitter&, llvm::CodeGenTarget&) ()
#5  0x00000000004cf134 in llvm::EDEmitter::run(llvm::raw_ostream&) ()
#6  0x000000000056840e in main ()

Then inspect in the debugger the instruction causing this.

[Quuxplusone]

This is a bug in sean's enhanced disassembly stuff. It is (incorrectly) reimplementing the asm string parsing logic in AsmWriterEmitter.cpp. I requested that he factor hte code in AsmWriterEmitter.cpp out to be stand alone logic and use it from both the ED and AsmWriterEmitter code.

[Quuxplusone]

Thanks for looking into this.  I only noticed the problem because dragonegg
does not generate exception handling code yet.  Normally the throw-catch would
be invisible.  Perhaps that's a mistake.  This code in EDEmitter.cpp is
responsible:

317   try {
318     operandIndex = inst.getOperandNamed(operand);
319   }
320   catch (...) {
321     return -1;
322   }

Maybe it should print the message attached to the exception before
returning -1, what do you think?

[Quuxplusone]

I have begun the refactoring process:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095879.html

[Quuxplusone]

Completed the refactoring:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095894.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095925.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095926.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100208/095929.html

Duncan, please let me know whether this bug has been fixed for you.

[Quuxplusone]

Thanks for fixing this Sean!  Tblgen is no longer throwing any exceptions
during the LLVM build.