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

[Richard Biener <richard dot guenther at gmail dot com>]

On Wed, Jul 29, 2015 at 6:25 PM, Abe <abe_skolnik@yahoo.com> wrote:
>> Well.  We don't generally introduce regressions with changes.
>
>
> Understood.  Regressions are bad, of course.  TTBOMK the
> regressions in question are temporary.  Once they are gone,
> I think we can then look at whether or not we still
> need to keep the old if converter in trunk.  Ideally,
> it eventually becomes redundant and unneeded.
>
>
>> (well, the patch still needs review -
>
>> I hope to get to that this week).
>
> 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.

I'm not sure we want two if-converters.  What we do want is avoid
using a scratch-pad if it is safe to do (for loads and stores)
and if the user tells us he is fine with store data races (for stores).

Does the "new" if-converter get rid of the analysis code that
determined "safe"?  If so you should re-instantiate that.

Richard.

> Regards,
>
> Abe