This morning I finished the transition which enables view classes for fmpzxx. Unfortunately, as it turns out, this pushes the compiler too far. The optimizer produces correct but incredibly crappy code. (Interestingly enough, the optimizers in various versions of gcc all seem to optimize some functions well, and fail hilariously at others. No version can do all my test, but every test can be done by some version. What sort of rubbish is that??) After some quick discussion on the gcc-help mailing list, it seems like I may have placed too much confidence in the capability of compiler optimizers.
I have now come up with a third strategy, which should allow the compiler to keep producing good code as long as no "views" are involved, while still retaining all the features when views are involved.
Hopefully I can explain details tomorrow, after implementing the new idea. Fingers crossed...
It's bizarre that source code plays such an important part in gcc's optimisations and that they don't optimise this stuff a bit better further down. I wonder how clang performs in comparison.
ReplyDeleteClang doesn't actually do better. Interestingly enough, it shows precisely the same behaviour as gcc in this regard. I suspect this is because they use similar optimizations, at least at some level. Apparently - and this is where it shows that I know very little about compiler internals, at an early stage they estimate the number of free registers, and this influences the behaviour of the optimizer (in particular with regard to which local variables to allocate stack space to, etc). If it later turns out that a lot of intermediates can be eliminated (so that more registers are free), nothing is done to re-visit the old choices.
ReplyDeleteI don't know why that is a sensible thing to do; but I suppose the main problem with optimizing is that it is just very hard. I guess the art of compiler implementation (TM) is to strike a balance between good optimization and avoiding quadratic (or worse) algorithms.