From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70861 invoked by alias); 31 Jul 2015 18:08:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 70851 invoked by uid 89); 31 Jul 2015 18:08:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: nm5-vm2.bullet.mail.ne1.yahoo.com Received: from nm5-vm2.bullet.mail.ne1.yahoo.com (HELO nm5-vm2.bullet.mail.ne1.yahoo.com) (98.138.90.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 31 Jul 2015 18:08:35 +0000 Received: from [98.138.100.116] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jul 2015 18:08:33 -0000 Received: from [98.138.226.30] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jul 2015 18:08:32 -0000 Received: from [127.0.0.1] by smtp201.mail.ne1.yahoo.com with NNFMP; 31 Jul 2015 18:08:32 -0000 X-Yahoo-SMTP: RhyaqECswBCSKHdmagqyBBwGHjobejNv Message-ID: <55BBB99F.6060003@yahoo.com> Date: Fri, 31 Jul 2015 18:29:00 -0000 From: Abe User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Richard Biener CC: Alan Lawrence , "gcc-patches@gcc.gnu.org" , Sebastian Pop 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 References: <55A961C1.1070206@yahoo.com> <55B7C27B.9000406@yahoo.com> <55B8FE61.7060008@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2015-07/txt/msg02706.txt.bz2 [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