[PATCH] D47430: TableGen: Streamline the semantics of NAME

Simon Tatham via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue May 29 09:41:05 PDT 2018


simon_tatham added inline comments.


================
Comment at: docs/TableGen/LangRef.rst:151
+to the name of the instantiating ``def`` or ``defm``. The result is undefined
+if the class is instantiated by an anonymous record.
 
----------------
I haven't fully got my head round all of this, but this new description of `NAME` doesn't quite seem to match the text in index.rst:

> Each `def` record has a special entry called "NAME". This is the name of the record ("`ADD32rr`" above). In the general case `def` names can be formed from various kinds of string processing expressions and `NAME` resolves to the final value obtained after resolving all of those expressions. The user may refer to `NAME` anywhere she desires to use the ultimate name of the `def`.

The general intention seems to be the same (if you refer to `NAME` in some expression in a class declaration, then each def that inherits that expression gets it evaluated in terms of that def's own name). But the old text says that `NAME` is also a property of the final def, whereas the new text seems to suggest that it's a more transient entity that never _really_ exists in the def but is just something classes can refer to while everything's being set up.

In my JSON backend (D46054) I manually filled in the `NAME` field in the JSON dict for every output def, because that text in `index.rst` said it should be there. But if that's not a reflection of reality any more, perhaps I should rename that field to `!name` to mark it as one of the extra pieces of JSON-level metadata?


Repository:
  rL LLVM

https://reviews.llvm.org/D47430





More information about the llvm-commits mailing list