4 ms·
Fantastic post. Just one comment: > This is a fair amount of optimisation passes and it would have been too time consuming to try them one by one I loved the
by wfunction 9y ago
Fantastic post. Just one comment:
> This is a fair amount of optimisation passes and it would have been too time consuming to try them one by one
I loved the fact that they used bisection, but then I was shocked to read this. This isn't the case at all unless you're extremely unlucky. If you just do bisection again, you can test with half the flags on and off, keeping the other half off. You can frequently discard half the flags this way, to narrow down the set, and on average it should be much faster than testing each one by one.
- CJefferson 9y agoUnfortunately that often doesn't work well for optimisation passes, as many passes end up relating to each other. However, you can still keep removing sets of optimisations and hope the bug remains, and do a final pass where you remove each optimisation one at a time. Another problem is that in the past I found compiler bugs from running unusual sets of optimisation passes.
- pklausler 9y agoA useful technique in the design of an optimizing compiler is to include an "odometer test" on all endomorphic discretionary transformations. E.g., at a spot where one has a big go/no-go predicate that determines whether a change to the program is valid and beneficial, add a final term that's a call to a routine that returns true if odometer++ < limit. You can then use bisection on that limit and zero in quickly on the failing change. This function is also a great place to put logging. I typically make it look like a printf() that returns a Boolean.