From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98608 invoked by alias); 7 May 2018 14:28:52 -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 97776 invoked by uid 89); 7 May 2018 14:28:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=anticipate, obscure, fairly, higher X-HELO: mail-yw0-f176.google.com Received: from mail-yw0-f176.google.com (HELO mail-yw0-f176.google.com) (209.85.161.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 May 2018 14:28:49 +0000 Received: by mail-yw0-f176.google.com with SMTP id l142-v6so7445876ywc.11 for ; Mon, 07 May 2018 07:28:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UQxgafmFA27GcrTg7HNFBtwdQA6MLmYSUneVTOxVB6w=; b=QaBdfHL4loYW+5lMHafjMvjNNHNth1SPUA1jHJGkneoIddNJnEVHvNKNuSQES2jsOx eA5zIkuqwcBfeHYZq0VZfL+FPmUgdHzva0QXdgMusGpfNWYk5lqXumAO9K88flTo3f6e uB6GPXP8JbpiS1Vu7J2i1n0HWStgHlUJt5rMNhiLRvEHz/JmK+/qeCnoULJf0wQmZkPS e6QxP52y48pzPJqkHJ8eQVTL00hrGTD5T78GbQ/bV+BEq+hHsk0hT4XOMK2nxSz43gXa CH4P+9pnj5inJL8j2AJuF58UClJp3CFyrSaWvCw9G+Z+IRzdySzBY79PhkPIYXQwB2qJ v0EQ== X-Gm-Message-State: ALQs6tAcfhb5A0sxGpbNTSy+mPZMBOnfsjTg/lNinOdYbMWXsWeP7uGQ ezNkcKhS9bkbYoC8oSEw4xnYGA== X-Google-Smtp-Source: AB8JxZpf+Vepdp9MQRMAsakAjKvT0Km3Tvbf04lZyUPfFd6RR8kbGWHTeg02dku+PMfjvQdvyaDi9w== X-Received: by 2002:a81:b54d:: with SMTP id c13-v6mr637076ywk.328.1525703327693; Mon, 07 May 2018 07:28:47 -0700 (PDT) Received: from [192.168.6.17] ([24.213.126.67]) by smtp.gmail.com with ESMTPSA id v125-v6sm10283202ywg.75.2018.05.07.07.28.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 May 2018 07:28:46 -0700 (PDT) Subject: Re: [PATCH, v2] Recognize a missed usage of a sbfiz instruction From: Luis Machado To: Kyrill Tkachov , gcc-patches@gcc.gnu.org Cc: james.greenhalgh@arm.com, Richard.Earnshaw@arm.com References: <5A747C58.8020501@foss.arm.com> <1517929440-7534-1-git-send-email-luis.machado@linaro.org> <5A7C3921.7020006@foss.arm.com> Message-ID: Date: Mon, 07 May 2018 14:28:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00283.txt.bz2 Hi, On 02/08/2018 10:45 AM, Luis Machado wrote: > Hi Kyrill, > > On 02/08/2018 09:48 AM, Kyrill Tkachov wrote: >> Hi Luis, >> >> On 06/02/18 15:04, Luis Machado wrote: >>> Thanks for the feedback Kyrill. I've adjusted the v2 patch based on your >>> suggestions and re-tested the changes. Everything is still sane. >> >> Thanks! This looks pretty good to me. >> >>> Since this is ARM-specific and fairly specific, i wonder if it would be >>> reasonable to consider it for inclusion at the current stage. >> >> It is true that the target maintainers can choose to take >> such patches at any stage. However, any patch at this stage increases >> the risk of regressions being introduced and these regressions >> can come bite us in ways that are very hard to anticipate. >> >> Have a look at some of the bugs in bugzilla (or a quick scan of the >> gcc-bugs list) >> for examples of the ways that things can go wrong with any of the >> myriad of GCC components >> and the unexpected ways in which they can interact. >> >> For example, I am now working on what I initially thought was a >> one-liner fix for >> PR 84164 but it has expanded into a 3-patch series with a midend >> component and >> target-specific changes for 2 ports. >> >> These issues are very hard to catch during review and normal testing, >> and can sometimes take months of deep testing by >> fuzzing and massive codebase rebuilds to expose, so the closer the >> commit is to a release >> the higher the risk is that an obscure edge case will be unnoticed and >> unfixed in the release. >> >> So the priority at this stage is to minimise the risk of destabilising >> the codebase, >> as opposed to taking in new features and desirable performance >> improvements (like your patch!) >> >> That is the rationale for delaying committing such changes until the >> start >> of GCC 9 development. But again, this is up to the aarch64 maintainers. >> I'm sure the patch will be a perfectly fine and desirable commit for >> GCC 9. >> This is just my perspective as maintainer of the arm port. > > Thanks. Your explanation makes the situation pretty clear and it sounds > very reasonable. I'll put the patch on hold until development is open > again. > > Regards, > Luis With GCC 9 development open, i take it this patch is worth considering again? Thanks, Luis