Abe wrote:
I`m uncertain to what that is intended to refer, but I believe Sebastian would
agree that the new if converter is safer than the old one in terms of
correctness at the time of running the code being compiled.
>
even if they take us a step backwards from a performance standpoint.
For now, we have a few performance regressions, and so far we have found that
it`s non-trivial to remove all of those regressions.
We may be better off pushing the current patch to trunk and having the
performance regressions currently introduced by the new if converter be fixed
by later patches.
Pushing to trunk gives us excellent "visibility" amongst GCC hackers, so the code will
get more "eyeballs" than if it lingers in an uncommitted patch or in a branch.
I, for one, would love some help in fixing these performance regressions. ;-)
If fixing the performance regressions winds up taking too long, perhaps the
current imperfect patch could be undone on trunk just before a release is
tagged,
and then we`ll push it in again when trunk goes back to being allowed to be unstable?
TBH my two cents would be that a performance-regressed, but correct, compiler,
is far better to release, than a performance-"improved" one that generates
unsafe code (e.g. with extra faults in the straightforward single-threaded case!)...
--Alan
