It's kind of troubling that you can't create test cases that start with DAG as opposed to bitcode .ll.
It's very tedious sometimes to go through and make sure that you have really tested all your patterns and sometimes the compiler changes and it stops generating those patterns but may resume generating them later.
So if you make a change at a time when it's not generating them, then there are two issues:
1) you can't test them. you might think you did but those patterns are not being generated any more
2) later when the patterns reappear, now you have compiler code that has never been tested.
Do you have any suggestions about how to address this?
-- Sean Silva
Ideally we would define an ascii representation for DAGS. It should be possible to start the compiler from the DAGS as opposed to LLVM assembler bitcode. It should also be possible to compile a C file or LLVM assembler bitcode file and save off the DAGS ascii file. Believe it or not, they had this over 30 years ago with the PQCC (Production Quality Compiler Compiler ) project at Carnegie Mellon. Intermetrics where I worked had a commercial version of this and later Tartan Laboratories. Any phase of the compiler had an ascii representation that could be parsed into binary stuctures and then submitted to that phase and optionally propagated to later phases. You could also save off the state of any phase in ascii too. So you could write test cases for optimizations and code generation that were reproducible and such. In those days they used various YAML ancient precursors like LG and IDL. We used to jokingly call the PQCC project PQTG (Product Quality Thesis Generator). Reed
I know Bill’s put a fair bit of thought into serialization of the SelectionDAG and MachineInstr layers of the compiler. It’s a significant challenge due the ordering requirements, but it’s (obviously) not impossible and would have a very large amount of value.
-Jim