On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
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.
So I chose to reply to this one (and will refrain from replying to other but try
to address comments there).
First, while the LTO approach works it's quite overkill in the details
it "dumps"
and thus it's too closely tied to our internal bits which means testcases will
bitrot too quickly for the number one goal of having human
maintainable testcases.