From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104220 invoked by alias); 14 Nov 2017 00:42:44 -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 104209 invoked by uid 89); 14 Nov 2017 00:42:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=philosophy, wasted, sessions, daily X-HELO: mail-oi0-f65.google.com Received: from mail-oi0-f65.google.com (HELO mail-oi0-f65.google.com) (209.85.218.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Nov 2017 00:42:43 +0000 Received: by mail-oi0-f65.google.com with SMTP id r190so3527099oie.6 for ; Mon, 13 Nov 2017 16:42:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=fKonNgNr3/azYHTvsBpQSUK7015yJ2qjEZQmxKPcMlA=; b=Y+Erx4ecLmb7yYZOturVMMKm8FRIQR/VE+uWSjj71vE/TL7WcZPJkRy5hdmuH8t02o md6vaa83eZGSjQk5+9iGHC3IXQULZPOayDfldjQQK2cgokurdT5VRVIAkeFEbjfRGRgh JPx1BgG2izKt+ILnFOKVzF/Yvwj2F9SL4oMi2VZTDiFUlwOCTpOVU3LbdYU7X3ZXwgCb ehloJGGkJkcqRunXrdZ9SLrnV8843cpR8t2zzeEDmWoSiaILBKyE42lgXsuEAqXcP7kh VgMDLWupmVBvPfS4AJfN6LIj+Q5tpta/VN9Y8IRslBLfmzs8JE1MaWoXEgaEjV+O2NIo VR+Q== X-Gm-Message-State: AJaThX6gBFOfx0uMrf1jkYkitzTB4b6zaWXMJ8SGbRLk4GE8X6uCAxO9 XwdoZ5i0CKuChdnlGmJ5gvE= X-Google-Smtp-Source: AGs4zMaV4onD/EResihfqAF8TAFPdXM+EByJq0RRw1M3Of9joNzdaRRysTqCWZ9eoN0FZeTL/AlbAw== X-Received: by 10.202.208.196 with SMTP id j65mr4375814oiy.185.1510620161384; Mon, 13 Nov 2017 16:42:41 -0800 (PST) Received: from localhost.localdomain (75-171-240-43.hlrn.qwest.net. [75.171.240.43]) by smtp.gmail.com with ESMTPSA id j92sm8341955otc.35.2017.11.13.16.42.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 16:42:40 -0800 (PST) Subject: Re: [001/nnn] poly_int: add poly-int.h To: Jeff Law , gcc-patches@gcc.gnu.org, richard.sandiford@linaro.org 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> From: Martin Sebor Message-ID: <824f5b7a-186e-1f32-04a7-4fb6cb06942a@gmail.com> Date: Tue, 14 Nov 2017 01:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <878tf9vjip.fsf@linaro.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01035.txt.bz2 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 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. Martin