Re: Another benefit of the new if converter: better performance for half hammocks when running the generated code on a modern high-speed CPU with write-back caching, relative to the code produced by the old if converter given the same source code

[Abe <abe_skolnik@yahoo.com>]

[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