From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11658 invoked by alias); 14 Nov 2017 09:39:06 -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 11644 invoked by uid 89); 14 Nov 2017 09:39:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=numerical, meaningful X-HELO: mail-wr0-f172.google.com Received: from mail-wr0-f172.google.com (HELO mail-wr0-f172.google.com) (209.85.128.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Nov 2017 09:39:04 +0000 Received: by mail-wr0-f172.google.com with SMTP id u40so16890187wrf.10 for ; Tue, 14 Nov 2017 01:39:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=vjE2FYHAwu2+pFWMTC5yZz8fCoChdLpHh1tbjgS0NwA=; b=nhHiTmmZyBm082J54GAsDkNsAU6QkEXOnRPIqyI/NIjCzUvF9AxG/CfyImN00eLdM4 fWpei0GHsHeDLOA4byfuPQhPnRKnzvr89BrvazrHeEp/JpiJImcZHLr5uBaYIz+0R9Z6 I7XXFcCzQlhzXxQ4HpDYj6gKyXpxK80WNMLmF5nCgOAjG/Sfl0KhoMT+4hxADPCzmox2 uBOoIZ13ttFAxVCdp0AMJdQDs3KT2gN18aP4F6TUkzV+mHCrPalrylV9nuw7Z0/mKE8E 1bjuSyMCotRdgpYypUxvlJGzZGvqTJRzIZaUDXahuY9D0samSOYrYhbLlJCVjn2t1iaQ VN9g== X-Gm-Message-State: AJaThX5P2IPCIQZ6/U0Bsmnc2Jnigo4T/iUnxGHxyP87oRjvNy1Kkwa6 VrAbIWcrpTv5vZmm7KVyGGJqUz8JUPs= X-Google-Smtp-Source: AGs4zMaYMtssQnHSZstXmHa7bHHpFwZ1nrdI/Q3b8d+0Or5gbj5konP4D8rNmCRcIiAR5EO4ISs1zQ== X-Received: by 10.223.129.41 with SMTP id 38mr10281989wrm.57.1510652341792; Tue, 14 Nov 2017 01:39:01 -0800 (PST) Received: from localhost ([2.25.234.120]) by smtp.gmail.com with ESMTPSA id o70sm59631972wrb.62.2017.11.14.01.39.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 14 Nov 2017 01:39:00 -0800 (PST) From: Richard Sandiford To: Martin Sebor Mail-Followup-To: Martin Sebor ,Jeff Law , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org Cc: Jeff Law , gcc-patches@gcc.gnu.org Subject: Re: [001/nnn] poly_int: add poly-int.h References: <871sltvm7r.fsf@linaro.org> <87vaj5u7id.fsf@linaro.org> <87po8t5d55.fsf@linaro.org> <1b724f75-7515-08f7-a783-d86fb1fe8bf8@gmail.com> <87375oww6b.fsf@linaro.org> <52db2aa0-43cb-ab73-d5ff-0347a4cfee10@gmail.com> <87r2t8pqv3.fsf@linaro.org> <87lgjfpv78.fsf@linaro.org> <878tf9vjip.fsf@linaro.org> <824f5b7a-186e-1f32-04a7-4fb6cb06942a@gmail.com> Date: Tue, 14 Nov 2017 09:46:00 -0000 In-Reply-To: <824f5b7a-186e-1f32-04a7-4fb6cb06942a@gmail.com> (Martin Sebor's message of "Mon, 13 Nov 2017 17:42:39 -0700") Message-ID: <87shdhtd1l.fsf@linaro.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-11/txt/msg01053.txt.bz2 Martin Sebor writes: > On 11/13/2017 04:36 PM, Richard Sandiford wrote: >> Jeff Law writes: >>> On 11/09/2017 04:06 AM, Richard Sandiford wrote: >>> >>>>> Let me say at the outset that I struggle to comprehend that a few >>>>> instructions is even a consideration when not optimizing, especially >>>>> in light of the bug the macro caused that would have been prevented >>>>> by using a function instead. But... >>>> >>>> Many people still build at -O0 though. One of the things I was asked >>>> for was the time it takes to build stage 2 with an -O0 stage 1 >>>> (where stage 1 would usually be built by the host compiler). >>> I suspect folks are concerned about this because it potentially affects >>> their daily development cycle times. So they're looking to see if the >>> introduction of the poly types has a significant impact. It's a >>> legitimate question, particularly for the introduction of low level >>> infrastructure that potentially gets hit a lot. >>> >>> Richard, what were the results of that test (if it's elsewhere in the >>> thread I'll eventually find it... >> >> On an x86_64 box I got: >> >> real: +7% >> user: +8.6% >> >> for building stage2 with an -O0 -g stage1. For aarch64 with the >> NUM_POLY_INT_COEFFS==2 change it was: >> >> real: +17% >> user: +20% >> >> That's obviously not ideal, but C++11 would get rid of some of the >> inefficiencies, once we can switch to that. > > For the purposes of this discussion, what would the numbers look > like if the macro were replaced with the inline function as I > suggested? > > What impact on the numbers would having the default ctor actually > initialize the object have? (As opposed to leaving it uninitialized.) I was objecting to that for semantic reasons[*], not performance when built with -O0. I realise you don't agree, but I don't think either of us is going to convince the other here. > I don't want to make a bigger deal out of this macro than it > already is. Unlike the wide int constructors, it's > an implementation detail that, when correct, almost no-one will > have to worry about. The main reason for my strenuous objections > is not the macro itself but the philosophy that performance, > especially at -O0, should be an overriding consideration. Code > should be safe first and foremost. Otherwise, the few cycles we > might save by writing unsafe but fast code will be wasted in > debugging sessions. But the macro was originally added to improve release builds, not -O0 builds. It replaced plain assignments of the form: r.coeffs[0] = ...; Using an inline function instead of a macro is no better than the original call to operator=(); see the mem_ref_offset figures I gave earlier. Thanks, Richard [*] Which were: 1) Not all types used with poly_int have a single meaningful initial value (wide_int). 2) It prevents useful static warnings about uninitialised variables. The fact that we don't warn in every case doesn't defeat this IMO. 3) Using C++11 "= default" is a good compromise, but making poly_ints always initialised by default now would make it too dangerous to switch to "= default" in future. 4) Conditionally using "= default" when being built with C++11 compilers and something else when being built with C++03 compilers would be too dangerous, since we don't want the semantics of the class to depend on host compiler. 5) AFAIK, the only case that would be handled differently by the current "() {}" constructor and "= default" is the use of "T ()" to construct a zeroed T. IMO, "T (0)" is better than "T ()" anyway because (a) it makes it obvious that you're initialising it to the numerical value 0, rather than simply zeroed memory contents, and (b) it will give a compile error if T doesn't have a single zero representation (as for wide_int). Those are all independent of whatever the -O0 performance regression would be from unconditional initialisation.