✧✦Catherine✦✧every compiler in existence expands until it includes a buggy, incomplete, and frustratingly slow copy of TableGen (e.g. TableGen). once that happens someone writes a new, simpler compiler
iximeow@whitequark we have always been at war with tablegen
eddybwas looking at MLIR as perhaps a less cursed way to e.g. ingest LLVM IR w/o FFI (plus ClangIR could give access to C/C++ information lost in LLVM IR)
then I found out that:
- MLIR heavily relies on TableGen
- MLIR dialects can invent arbitrary syntax for their constructs!
(through TableGen generating C++ code, AIUI)
(there's `-mlir-print-op-generic`, e.g.: https://godbolt.org/z/GhWMaWb5j but even that makes me wonder if the MLIR bytecode would be easier to work with instead...)
Compiler Explorer - C++ (x86-64 clang (clangir))
struct S { S(int); virtual void f(); }; struct T : S {}; S globalS(5); void mayThrow(); int doThings(S *s) { int retval = 1; try { if (T *t = dynamic_cast<T *>(s)) mayThrow(); } catch (int i) { retval = i; } catch (...) { retval = 0; } return retval; }
@whitequark @iximeow naively I was hoping for something more like e.g. https://mlir.llvm.org/docs/Dialects/IRDL/ and better interoperability even without FFI
but when you already have a hammer...
(also, even IRDL has e.g. a way to inject C++ code from a string: https://mlir.llvm.org/docs/Dialects/IRDL/#irdlc_pred-irdlcpredop)