On 03/07/2016 11:33 AM, David Malcolm wrote:
So for testing specific passes, I'd much rather have an input format for testing individual passes that: * can be easily generated by GCC from real test cases * ability to turn into unit tests, which implies: * human-readable and editable * compatibility and stability: can load gcc 7 test cases into gcc 8; have e.g. gcc 6 generate test cases * roundtrippable: can load the format, then save out the IR, and get the same file, for at least some subset of the format (consider e.g. location data: explicit location data can be roundtripped, implicit location data not so much). ...which suggests that we'd want to use gimple dumps as the input format to a test framework - which leads naturally to the idea of a gimple frontend.
We already read and write gimple IL in LTO, we just do it in binary form. I think the kind of effort you are talking about here is best placed in attaching a gimple parser to LTO, thus giving LTO the ability to read and write textual gimple as well as the current binary form. The current dump format could in theory be a starting point, but its clearly missing hunks of stuff. there is probably a better representation.
LTO already knows all the bits required to reconstruct gimple. The definition of the textual representation can make intelligent choices about defaults so that you don't have to specify every single bit in the textual form that the binary form requires. ThIs seems far easier to me than starting with the incomplete form that the current dumps generate and trying to discover what other bits need to be added to properly reconstruct the IL. I think its hard to get a lot of the subtle things right. I also think the scope of defining and reading/writing should be relatively manageable. We can optimize the details once its working.
It would also be very useful then to have LTO enhanced so that it can read and write before or after any pass... Then we can unit test any pass by injecting the IL immediately before the pass.. No jumping through any hoops to make sure the pass you care about sees the exact IL you want.. That is also a good proof that the LTO form (both binary and text) does fully represent gimple. We can also use this output as our debugging dumps and archive the current dumper.
As gimple changes and evolves the result is only one place to worry about for reading and writing... and as we progress (slowly) towards uncoupling the middle/backend from the front ends, we'd have a single well defined "front end" for gimple that accepts binary or text.
Andrew
