On Sun, 18 Oct 2020, Maciej W. Rozycki wrote:
=== gcc Summary ===
# of expected passes 110142
# of unexpected failures 1821
# of unexpected successes 7
# of expected failures 566
# of unresolved testcases 30
# of unsupported tests 3131
/scratch/vol0/vax-netbsd/obj/gcc/gcc/xgcc version 11.0.0 20200704 (experimental) (GCC)
[...]
With all the regressions out of the way the next step is code quality,
which has become a little lower, so it has to be addressed now.
Current results:
=== gcc Summary ===
# of expected passes 110157
# of unexpected failures 1820
# of unexpected successes 7
# of expected failures 566
# of unresolved testcases 32
# of unsupported tests 3131
meaning even the single LTO regression is now gone and we are down to the
original number of 1821 failures minus one for an unrelated obvious fix I
made to one of the VAX-specific test cases nobody has obviously run for
years now (the slightly higher count of passes compared to the original
results comes from extra test cases I have since added).
I have updated the changes significantly, including some required
modifications to generic GCC code needed for scenarios not previously
considered. I have also instrumented the test harness to run `size' on
all executables run on the remote machine and record the output in the
test log. That has turned out to collect 17253 samples.
With that in place I ran a simple (well, maybe not so much) shell command
to diff the `size' results and report any test cases whose text size has
not decreased with my change in place. This resulted in these test cases
only having grown with the old and the new text sizes respectively shown:
2317 2327 ./pr42833.exe
2367 2383 ./pr42833.exe
2367 2383 ./pr42833.exe
2367 2383 ./pr42833.exe
2323 2333 ./pr42833.exe
2367 2383 ./pr42833.exe
2109 2117 ./pr46316.exe
2073 2075 ./pr46316.exe
2073 2075 ./pr46316.exe
2073 2075 ./pr46316.exe
2023 2025 ./pr46316.exe
2073 2075 ./pr46316.exe
5929 5983 ./strlenopt-68.exe
2621 2623 ./interchange-0.exe
2419 2421 ./interchange-15.exe
2663 2665 ./interchange-5.exe
2419 2421 ./uns-interchange-15.exe
(many test cases are run consecutively at different optimisation levels
and unfortunately many of them do not care to make the file names of the
binaries produced unique, consequently overwriting ones previously built).
I'll yet see if there is anything significantly wrong with them, but
otherwise I consider my code ready for final verification and I do not
consider these size regressions showstoppers for change submission. After
all the code size with 17253 - 17 = 17236 samples has decreased, and any
corner-case pessimisations can be sorted out, where feasible, anytime.
I have now refreshed GCC sources, so that verification for upstream
submission is run with the current version rather than one from Jul 4th,
which I considered stable enough to play with. As I intend to run full
rather than C frontend only testing now I expect it to take a bit longer
(for the record, with GCC built optimised C frontend verification time has
decreased to ~11 hours from previous ~12.5 hours).
Once that's complete I'll do final patch folding into self-contained
pieces (e.g. to merge code updates with the respective test case additions
which I keep as separate changes for easier verification in development)
and post the resulting series upstream. I yet plan to add a number of
proper test cases though to verify that the compare elimination pass does
its job, using the template I have made for my own verification already.
Maciej