On 03/09/2016 10:47 AM, Richard Biener wrote:
On Wed, Mar 9, 2016 at 3:27 PM, Andrew MacLeod <amacl...@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.
The binary form is clearly tied to a lot of implementation bits, but I
would think a lot of those bits have a reasonable default value that
wouldn't have to be explicitly expressed in textual form, but could be
if so desired via attributes, tags, new keywords, or whatever.
The current dumps are C-like and could work as a decent starting point
for textual gimple input/output. From the LTO vantage point, you can
see all the other bits which might need to be expressed, and can get to
them later. That is "merely" the follow on hard work of flushing out
the details :-)
I'd just hate to see a lot of work go into it and have it made
completely redundant in a few years by the presence of a new lto
reader/writer than can do the same job. Of course that's still blue-sky
stuff and could never happen.
No matter what approach is taken, it would be good to keep in mind the
possibility of enhancing it to be the LTO text reader so that decisions
aren't made which make that impractical.. I don't think its on my hit
list for a while yet... but it would be really nice to be able to
leverage any work that is done in this direction. It would be ideal to
be able to simply add enhancements to whatever we have to provide the
rest of what LTO requires to be a complete reader/writer.
Andrew
