From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id 41F5D385801C for ; Tue, 22 Feb 2022 07:54:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 41F5D385801C Received: by mail-ed1-x52f.google.com with SMTP id bq11so13515630edb.2 for ; Mon, 21 Feb 2022 23:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Su7uKPRsBkiGHQQ4JRf1bR0kOhCawng9aLbrMpo9dck=; b=cJDEWmOsq8pKScEzxqXjg9EILrdCigQw2U2s+BeavDDV0yO6w/PSVrwEeWrtuMriIs aHwcQTZ2lUlVcJokbOr3aMKwiBCNw80C3T/temOfUPe7wb2aZQa+CduxEzJeTrIWTe92 pxCupxcgFhVk6iyf/Pq2dblw37KlB4ZBTyM7e8N6zeNBspDdTkYU0o7UN1mNmNW9KNj0 TpI5INLVfFx9/Y5p4f0ocoLiKl+q/Uyh/KkxtohfGQeAsufLADCyrFmywb47jHTmAtEU OimYeoAaus6rNMKe659xvprv3kMqtPFVUD21LZ6lb5CQngmVxrj3y0oaAVQpaXRyPpIW gerg== X-Gm-Message-State: AOAM531kTK+RDzXT5vdh//H4W4W2U5KaZl0nkq9iosi/itTU7zwZXamO Q+XqDFAQ9/L/D54oYHAboacMxOlEs3oMQm4oqFQ= X-Google-Smtp-Source: ABdhPJzsI6jQ8O6DO4QkZ+8V7Z17JG/yHeYXsyO+472wuYF5b+tcWzfX0423khixtQR175BloXeOXpdRFlrnPlgvDH0= X-Received: by 2002:a50:c048:0:b0:410:a2e6:eb66 with SMTP id u8-20020a50c048000000b00410a2e6eb66mr25649752edd.156.1645516450090; Mon, 21 Feb 2022 23:54:10 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Tue, 22 Feb 2022 08:53:59 +0100 Message-ID: Subject: Re: [PATCH] tree-optimization: [PR103855] Fold (type)X / (type)Y To: Zhao Wei Liew Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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, 22 Feb 2022 07:54:13 -0000 On Tue, Feb 22, 2022 at 5:01 AM Zhao Wei Liew via Gcc-patches wrote: > > On Tue, 22 Feb 2022 at 11:57, Zhao Wei Liew wrote: > > > > Hi, > > > > This is a partial optimization for PR103855. > > > > Initially, I looked into optimizing RTL generation or a more complex > > GIMPLE transformation so that we could optimize other cases as well, > > such as ((unsigned long long) short / int). > > > > However, that is a bit too complex for now. While I continue to look > > into that change, I've decided to implement this simpler match.pd > > transformation. > > > > Greatly appreciate any feedback on this patch or guidance for > > implementing the more advanced optimizations! > > > > Thanks, > > Zhao Wei > > Sorry, the original patch wasn't recognized as a text file. I've added > a .txt extension to make it explicit. A few comments - note the change is only appropriate for next stage1. Since we're currently in a regression fixing period reviews can be slow - do not hesitate to ping forgotten patches when stage1 opens again. +/* (type)X / (type)Y -> (type)(X / Y) + when the resulting type is at least precise as the original types + and when all the types are unsigned integral types. */ +(simplify + (trunc_div (convert @0) (convert @1)) + (if (INTEGRAL_TYPE_P (type) + && INTEGRAL_TYPE_P (TREE_TYPE (@0)) + && INTEGRAL_TYPE_P (TREE_TYPE (@1)) + && TYPE_UNSIGNED (type) + && TYPE_UNSIGNED (TREE_TYPE (@0)) + && TYPE_UNSIGNED (TREE_TYPE (@1)) + && TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1)) + && TYPE_PRECISION (type) >= TYPE_PRECISION (TREE_TYPE (@0))) + (convert (trunc_div @0 @1)))) since you are requiring the types of @0 and @1 to match it's easier to write && types_match (TREE_TYPE(@0), TREE_TYPE (@1)) that allows you to elide checks on either @0 or @1. I suppose the transform does not work for signed types because of the -INT_MIN / -1 overflow case? It might be possible to use expr_not_equal_to (@0, -INT_MIN) || expr_not_equal_to (@1, -1) (correctly written, lookup the existing examples in match.pd for the X % -Y transform) I'll note that as written the transform will not catch CST / (T)x or (T)x / CST since you'll not see conversions around constants. I'm not sure whether using (convert[12]? ...) or writing special patterns with INTEGER_CST operands is more convenient. There is int_fits_type_p to check whether a constant will fit in a type without truncation or sign change. When @0 and @1 do not have the same type there might still be a common type that can be used and is smaller than 'type', it might be as simple as using build_nonstandard_integer_type (MIN (@0-prec, @1-prec), 1 /*unsigned_p*/). In the past there have been attempts to more globally narrow operations using a new pass rather than using individual patterns. So for more complicated cases that might be the way to go. There's now also the ISEL pass which does pre-RTL expansion transforms that need some global context and for example can look at SSA uses. Richard.