[Abe wrote:]
After I`ve done the SPEC-based analysis, my next planned steps on this work are to disable the code that [in my WIP] currently causes conversion to be enabled by default when autovectorization is enabled, then to re-integrate the old converter and implement the switches that will give GCC users access to the modes I described in a recent email from me. You might prefer to delay your code review until I have that all done and a new version of the patch submitted.
[Richard wrote:]
I'm not sure we want two if-converters.
Not _permanently_, no. However, having the old one available and be the one that is activated -- [1] by default under conditions in which current GCC trunk activates if conversion by default, and [2] when the existing/old flags call for it -- allows us to have the old converter still apply in all cases in which it currently applies, to have the new converter in trunk so it has eyes on it and Sebastian and myself won`t be the only people working on it anymore [I hope ;-)]. The preceding will also make comparison of the two converters easier [use the same compiler build, just vary your flags] and more reliable [all other compiler components will be identical, so we have a stronger guarantee of apples-to-apples comparison]. All of that will help us make the new converter better and better until the old one becomes completely unneeded, at which point we can remove it and "massage" the user-visible flags and the semantics thereof -- ideally only doing this in a release just before the release of a new GCC major version number so we don`t introduce breaking changes in the middle of a major version number, of course. [not pretending to "teach" anybody anything here -- just showing that I, too, understand the basics of releasing decent software -- or at least _some_ of those basics ;-)]
What we do want is avoid using a scratch-pad
> if it is safe to do (for loads and stores) I strongly agree. In fact, TTBOMK that is a big part of improving the new converter so it no longer has performance regressions.
and if the user tells us he is fine with store data races (for stores).
Wouldn`t it be nice -- if we can do so without killing ourselves over it -- to only take the flag in question as _permission_ to generate a data race? IOW, it would be nice if a cost-model-based analysis would be able to tell us e.g. "for this loop, it`s worth it due to the many saved machine cycles" versus "for this loop, it`s not worth it: you only stand to save a cycle or two, and you potentially sacrifice some correctness in the process".
Does the "new" if-converter get rid of the analysis code that determined "safe"? If so you should re-instantiate that.
I don`t have a good answer for that right now and don`t anticipate having the correct answer soon enough that I should delay this reply IMO. I`ll get back to you on this question. Regards, Abe
