[PATCH] [TableGen] Do not link Predicate conditions if the 1st one wasn't emitted.

[Daniel Sanders]

I don't think the commit message explains this change very well. If we hadn't already discussed the problem off-list I'm not sure I would have understood what you meant. I'd have started with a subject like:

  [tablegen] Fix invalid code generation when the first predicate is not an AssemblerMatcherPredicate.

and then talked about the way it currently produces 'if ( && B)' in the body of the message.


================
Comment at: test/TableGen/PredicateOrderDisasm.td:3-5
@@ +2,5 @@
+
+// Check that we don't try to logically link together the 1st and 2nd generated
+// Predicate conditions if for the 1st Predicate we didn't actually emit
+// anything.
+
----------------
 

================
Comment at: test/TableGen/PredicateOrderDisasm.td:3-11
@@ +2,11 @@
+
+// Check that we don't try to logically link together the 1st and 2nd generated
+// Predicate conditions if for the 1st Predicate we didn't actually emit
+// anything.
+
+// In the example below, Pred1 is not an AssemblerPredicate, while Pred2 is.
+// When doing -gen-disassembler, we only care about AssemblerPredicate's, so
+// we don't emit the condition for Pred1, but we would still try to link the
+// condition for Pred2 with the (inexistent) one for Pred1 by emitting "&&".
+// This would result in invalid code being generated.
+
----------------
dsanders wrote:
>  
This is a bit strange to read. Maybe simply:
  Check that we don't accidentally generate code of the form 'if ( && B)'.
is enough.

================
Comment at: test/TableGen/PredicateOrderDisasm.td:37
@@ +36,2 @@
+
+// CHECK-NOT: ( && (Bits & arch::AssemblerCondition2))
----------------
It's better to check that the correct thing happens rather than check that the wrong thing doesn't happen.

http://reviews.llvm.org/D8294

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/