[PATCH] D43564: TableGen: Introduce an abstract variable resolver interface

Artem Belevich via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 23 14:38:24 PST 2018


tra accepted this revision.
tra added inline comments.
This revision is now accepted and ready to land.


================
Comment at: include/llvm/TableGen/Record.h:1631
+
+  virtual bool keepUnsetBits() const { return false; }
+};
----------------
nhaehnle wrote:
> tra wrote:
> > Please describe the purpose of this function. It's not clear what are those unset bits and why would we want (or not) to keep them.
> It's to do with keeping cross-references alive to represent instruction encodings. I'm adding a comment, see also http://nhaehnle.blogspot.de/2018/02/tablegen-3-bits.html
Interesting. This feature does not seem to be mentioned anywhere in the docs. It probably should be, though I'm not sure where. We have bare-bones syntax doc, very simple language introduction, and the list of back-ends. We currently don't have any good place for describing how tablegen does things. 

After these patches you're officially going to be the only person who can claim to understand it. :-) Any chance you could write few pages (separately from this patch)  that would give people an idea of what to expect from tablegen? I.e. how name resolution works, special cases like references to bits, etc.  That would be extremely valuable, IMO.



================
Comment at: lib/TableGen/Record.cpp:1837-1858
+Init *RecordResolver::resolve(Init *VarName) {
+  Init *Val = Cache.lookup(VarName);
+  if (Val)
+    return Val;
+
+  for (Init *S : Stack) {
+    if (S == VarName)
----------------
nhaehnle wrote:
> tra wrote:
> > Do we ever cache objects that get deallocated? 
> > If so, using pointers for cache is problematic VarName may have been deallocated and re-allocated to represent something else since it was cached. Perhaps you want to use fully qualified var name as the key instead.
> Inits are never deallocated (except on program shutdown). They are owned by the static pools from which they are allocated, see the various ::get function implementations.
OK.


Repository:
  rL LLVM

https://reviews.llvm.org/D43564





More information about the llvm-commits mailing list