TableGen backend API refactoring.

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 <>

~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 <> 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 <>. 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

Sure, knock yourself out.