News for hackers. Stuff that matters.
Re:Testing GCC by drfuchs on Monday February 13, 2017 @04:02PM (#13638732)
Great, but now how will you find out that a particular optimization pass hasn't been completely obviated by earlier passes, since you won't be looking for C code that actually triggers it?
Re:Testing GCC by greglindahl on Monday February 13, 2017 @05:28PM (#13639407)
I never got around to actually implementing the following in the PathScale compiler, but my idea was to add logging in all the places where allocations do something, and then create lists of optimizations that I expect to have successfully fired in various functions or programs. This would be especially handy for checking that new optimizations didn't disable important things for various SPECcpu benchmarks.
Re:Testing GCC by greglindahl on Monday February 13, 2017 @09:26PM (#13640690)
Sorry, "the places where optimizations do something". Didn't notice until after the edit window was long passed. I blame autocorrect :-)
Re:Testing GCC by correnos on Monday February 13, 2017 @04:22PM (#13638897)
Well, you could embed a machine-checked proof that instruction sequences of the targeted form will sometimes survive previous optimization passes and therefore the given optimization will always be contributing something.

But that's hard, so every compiler I've used leaves it to human engineering instead.

Re:Testing GCC by astrange on Monday February 13, 2017 @06:22PM (#13639812)
You can emit stats for time and # of instructions changed by each pass. gcc certainly does the first, don't remember the second.
Re:Testing GCC by bonzini on Monday February 13, 2017 @05:15PM (#13639288)
You can do both kinds of tests: check that a pass still optimizes some GIMPLE or RTL input the same way, and check that the C code is optimized the same way. In turn, the latter can either look at per-pass dumps, or at the final assembly code for one or more architectures.