[LLVMdev] TableGen backend API refactoring.

Sean Silva silvas at purdue.edu
Mon May 7 14:42:20 PDT 2012


tl;dr: is anyone opposed to making the interface to a TableGen backend be:

void MyBackend(RecordKeeper &, raw_ostream & /* maybe some other args, per
backend's needs */);

??

Currently, this is the "interface" for a TableGen backend:

struct TableGenBackend {
  virtual void anchor();
  virtual ~TableGenBackend() {}

  // run - All TableGen backends should implement the run method, which
should
  // be the main entry point.
  virtual void run(raw_ostream &OS) = 0;


public:   // Useful helper routines...
  /// EmitSourceFileHeader - Output a LLVM style file header to the
specified
  /// ostream.
  void EmitSourceFileHeader(StringRef Desc, raw_ostream &OS) const;

};

Let's go over this class's members one-by-one:

anchor(): hack to decrease link time and bloat <
http://llvm.org/docs/CodingStandards.html#ll_virtual_anch>

~TableGenBackend(): the standard virtual destructor so that we can
polymorphically delete. Except that we never polymorphically delete. Every
use of the backends is basically
`SubtargetEmitter(Records).run(OS);` and is hardcoded into the respective
TableGen.cpp file. No polymorphic creation ever happens. We never even
declare a variable using this type. This <
http://pastie.org/private/xhqaonrbarz3lf7b1gew6q> is all occurrences of
"TableGenBackend" in the LLVM source tree; that's a code smell if I've ever
seen one.

run(): this does the action, but given that it is only ever called
like `SubtargetEmitter(Records).run(OS);`, seems kind of pointless

EmitSourceFileHeader(): this is just a helper *function*, it doesn't rely
on instance state since it just blasts some hardcoded strings surrounding
the given StringRef into the raw_ostream it is given. It should not be a
method in the first place.

So basically, this class just needs to die. All of the
utils/TableGen/*Emitter.h files declaring subclasses of it can be merged
into a single "Backends.h" declaring a single function with the
aforementioned prototype for each one of the backends and all of the
backends can be their own nicely self-contained .cpp file.
Clang has its own backends, but the makeover would be identical.

I'll also take the opportunity to fill in the sorely needed TODO at the end
of <http://llvm.org/docs/TableGenFundamentals.html>. Finally :)))))

Finally, does anyone foresee me needing to make any changes to be build
system? If so, some advice would be appreciated.

Any objections?

--Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120507/49b32caa/attachment.html>


More information about the llvm-dev mailing list