This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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
- From: Abe <abe_skolnik at yahoo dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Alan Lawrence <alan dot lawrence at arm dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Sebastian Pop <sebpop at gmail dot com>
- Date: Fri, 31 Jul 2015 13:08:31 -0500
- Subject: 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
- Authentication-results: sourceware.org; auth=none
- References: <55A961C1 dot 1070206 at yahoo dot com> <CAFiYyc0MTHVT_7MBMpbx2K6vYLgZ5L37OPEaHPG_ey4qZAwnEw at mail dot gmail dot com> <55B7C27B dot 9000406 at yahoo dot com> <CAFiYyc2JRt6G0hOdshG0GftQF8+DOdOC-B7Y1hCMKXru4hZDtA at mail dot gmail dot com> <55B8FE61 dot 7060008 at yahoo dot com> <CAFiYyc1L2DYfHYbXuUfGh8+72Hf6=nH-spf2hi5RUh_ptekdhA at mail dot gmail dot 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