From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 28990385800B for ; Tue, 23 Nov 2021 03:09:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28990385800B Received: by mail-pl1-x636.google.com with SMTP id b11so15793116pld.12 for ; Mon, 22 Nov 2021 19:09:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=JONXSO6xQS6LNT29VrvIgvS/LWWmd7ZbDPozLbxQLKg=; b=IWsGUZ8aHNvcWaf9fXVGEjlIM7iOlKK06Lvx82fX9nWoAptHqNKleSoHdHBwtWbI8L 7fSCtHsBmXhTj6DrQHtqOWNdpYtSmoyS+6X8ZxReHj2daeEKU38rR4H0SufSfWGdi1bW VWCG591TTIhQjs+ICHm5u80R7qnQaHwGRjSYBKNR35tiE8wJ/tpk/2z78UKG/xxJRCbE aEItS8ra5j9sKeYPARZN1ae8Eu0ZCDGXId8TRzRJQ4zml+n6AzTLvfEJwx5RyBHaoJEO ukTLv7mrGcuQqykfgVh1e8tlflVxr1628H7Yf18rItsqktzC70NgnHH2Eg0Xs9gF30rR RmXA== X-Gm-Message-State: AOAM533wUAtOIbm9K37Adt7kUW8qwl2j/NM/+/pYOAjCJztcoIXsA1Xw y+EKMxw0SJOfoyoegsWEb0I= X-Google-Smtp-Source: ABdhPJymkHhVv29Z7Jmn93lG6f+C7dPkl2JEb9tbRLxOlDhENd622oCtGeWwkQLKIewS3Wi6o/tJBQ== X-Received: by 2002:a17:902:f092:b0:141:ccb6:897 with SMTP id p18-20020a170902f09200b00141ccb60897mr2699878pla.89.1637636949173; Mon, 22 Nov 2021 19:09:09 -0800 (PST) Received: from [172.31.0.175] (c-98-202-48-222.hsd1.ut.comcast.net. [98.202.48.222]) by smtp.gmail.com with ESMTPSA id h8sm11053590pfh.10.2021.11.22.19.09.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 19:09:08 -0800 (PST) Message-ID: <0e400521-74dd-9329-4d96-86152f38dcd5@gmail.com> Date: Mon, 22 Nov 2021 20:09:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [EXTERNAL] Re: [PATCH] PR tree-optimization/102232 Adding a missing pattern to match.pd Content-Language: en-US To: Richard Biener , Navid Rahimi Cc: "gcc-patches@gcc.gnu.org" References: From: Jeff Law In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2021 03:09:11 -0000 On 11/10/2021 1:35 AM, Richard Biener via Gcc-patches wrote: > On Tue, Nov 9, 2021 at 5:25 PM Navid Rahimi wrote: >> Hi Richard, >> >> Thank you so much for your detailed feedback. I am attaching another version of the patch which does include all the changes you mentioned. >> >> Bellow you can see my response to your feedbacks: >> >>> the canonical order of the plus is (plus:s (trunc_div ...) integer_onep) as >>> constants come last - you can then remove the 'c' >> Fixed. I was not aware of the canonical order. >> >>> you can use INTEGRAL_TYPE_P (type). >> Fixed. Didn't know about "type" either. >> >>> this test is not necessary >> Fixed. >> >>> But should we also optimize x * (2 + y/x) - y -> 2*x - y % x? So >>> it looks like a conflict with the x * (1 + b) <-> x + x * b transform >>> (fold_plusminus_mult)? That said, the special case of one >>> definitely makes the result cheaper (one less operation). >> For this special case, it does remove operation indeed. But I was not able to reproduce it for any other constant [1]. If it was possible to do it with other constants I would've changed the pattern to have be more general like "x * (C + y/x) - y -> C*x - y % x". Basically anything other than 1 wasn't a win. Regarding the "x * (1 + b) <-> x + x * b" transformation, it appears to me when there is a "- y" at the end "x * (1 + b)", there is opportunity to optimize. Without that "- y" I was not able to make any operation more performant. Either direction, looks like same amount of computation. >> >> 1) https://compiler-explorer.com/z/dWsq7Tzf4 >> >>> Please move the pattern next to the most relatest which I think is >> Fixed. >> >>> the return value of 1 is an unreliable way to fail, please instead call >>> __builtin_abort (); >> Fixed. >> >>> do we really need -O3 for this? I think that -O should be enough here? >> We don't specifically need that. But I realized that the optimization can happen in two different level at the compiler. It seems if you spread the computation over multiple statement like: >> int c = a/b; >> int y = b * (1 + c); >> return y - a; >> >> instead of : >> return b * (1 + a / b) - a; >> >> Then you have to have at least -O1 to have it optimized. Granted, I am not doing that in the testcase. In the new patch I am changing it to -O. Let me know if you have any suggestions. > -O is fine, generally at -O0 we shouldn't expect such transforms to > happen (but they still do, of course). > > The patch looks OK now. I've pushed this to the trunk for Navid. jeff