From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7B5AB3858D39 for ; Tue, 18 Jan 2022 16:56:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7B5AB3858D39 Received: from mail-qt1-f199.google.com (mail-qt1-f199.google.com [209.85.160.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-438-6hw6SeC8P3uIRSpdqembBw-1; Tue, 18 Jan 2022 11:56:21 -0500 X-MC-Unique: 6hw6SeC8P3uIRSpdqembBw-1 Received: by mail-qt1-f199.google.com with SMTP id f21-20020ac84655000000b002cae5b5722bso4052356qto.10 for ; Tue, 18 Jan 2022 08:56:21 -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=DOSwUr17VcPNwuasK7N7GwJPR21TMsSh5aNGBkS2R5c=; b=CGdxW6mnXwrZs4hFGVeTEnhQvSpbXBfVBCN3dSSTSj5C052fw44OAitl853hQ4iu0W +H+p3Ge3oMKasyNodj6KSGvhURpwBrCpuuTtRGCtEfVjmtb71LsehkSNz33m+dTMSNe1 5ImMzlmKcaS3KSgAB/VqtwrxCbVrIQoYqquDEAHawt9LboU2hYxmcyWD4i4DPRub/M9u 4de58HOPKvg7Y3KyHSJ9HoHTPXjL21EWEPRID+2G7m5nTM3qWhG5ifHe8X853PCFxnaT XfE9cAd2uf739PelUQdKH7m3UXqvzm0kZ8oMxfNQ7Dmud+gFV9+tHZDoQNFyK3ekGZXw pcyg== X-Gm-Message-State: AOAM5333R9zTG6N8q9h/Gu7P7dDFa9FIzQNtTdGit+gjzKstYXsBBMMV rz5LCafc4LaAEIPqkRUVy5BKZcAbxjMXqq8XNICVHjimtkMsT2xJSn2Cl4ZgkUkjVv7un42Yyny eGmQFYLv86pPP8vl3FQ== X-Received: by 2002:ad4:5baf:: with SMTP id 15mr23535027qvq.21.1642524980363; Tue, 18 Jan 2022 08:56:20 -0800 (PST) X-Google-Smtp-Source: ABdhPJzyrY2dSjjaeWP8HXIRTz72WrT3QWHI6BFnJQF4GCKX7U4nkPfNaOXl4hiraBhM1KXs1UH5uA== X-Received: by 2002:ad4:5baf:: with SMTP id 15mr23535000qvq.21.1642524979963; Tue, 18 Jan 2022 08:56:19 -0800 (PST) Received: from [192.168.1.149] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id f33sm11355625qtb.56.2022.01.18.08.56.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jan 2022 08:56:19 -0800 (PST) Message-ID: Date: Tue, 18 Jan 2022 11:56:18 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH] c++: Further address_compare fixes [PR89074] To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Richard Biener References: <20220106092416.GX2646553@tucnak> <494ae254-aff9-8be9-1cee-5ee42b6db593@redhat.com> <20220118101741.GW2646553@tucnak> <841aeb56-57a3-07b3-dbc0-a45ef0cca554@redhat.com> <20220118164048.GD2646553@tucnak> From: Jason Merrill In-Reply-To: <20220118164048.GD2646553@tucnak> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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, 18 Jan 2022 16:56:26 -0000 On 1/18/22 11:40, Jakub Jelinek wrote: > On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote: >>> Can you please comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1 >>> then? >> >> Done. > > Thanks. > >> About the rest of the patch, I thought I had seen richi comment on IRC (but >> can't find the comment now) that these cases where we could give a constant >> answer but decide not to because of C++ rules should be handled in the front >> end rather than generic code, which makes sense to me; that is, use >> folding_initializer only for giving more constant results, not for giving >> fewer constant results. Maybe add another flag for limiting constant >> results if we think it's significantly easier to recognize these cases in >> fold? > > I'm afraid avoiding the match.pd & fold-const code here would be a lot of > work. > The match.pd code looks like: > (for cmp (simple_comparison) > (simplify > (cmp (convert1?@2 addr@0) (convert2? addr@1)) > (with > { > poly_int64 off0, off1; > tree base0, base1; > int equal = address_compare (cmp, TREE_TYPE (@2), @0, @1, base0, base1, > off0, off1, GENERIC); > } > (if (equal == 1) > (switch > (if (cmp == EQ_EXPR && (known_eq (off0, off1) || known_ne (off0, off1))) > { constant_boolean_node (known_eq (off0, off1), type); }) > (if (cmp == NE_EXPR && (known_eq (off0, off1) || known_ne (off0, off1))) > { constant_boolean_node (known_ne (off0, off1), type); }) > (if (cmp == LT_EXPR && (known_lt (off0, off1) || known_ge (off0, off1))) > { constant_boolean_node (known_lt (off0, off1), type); }) > (if (cmp == LE_EXPR && (known_le (off0, off1) || known_gt (off0, off1))) > { constant_boolean_node (known_le (off0, off1), type); }) > (if (cmp == GE_EXPR && (known_ge (off0, off1) || known_lt (off0, off1))) > { constant_boolean_node (known_ge (off0, off1), type); }) > (if (cmp == GT_EXPR && (known_gt (off0, off1) || known_le (off0, off1))) > { constant_boolean_node (known_gt (off0, off1), type); })) > (if (equal == 0) > (switch > (if (cmp == EQ_EXPR) > { constant_boolean_node (false, type); }) > (if (cmp == NE_EXPR) > { constant_boolean_node (true, type); }))))))) > and > (for minmax (min max) > cmp (lt gt) > (simplify > (minmax (convert1?@2 addr@0) (convert2?@3 addr@1)) > (with > { > poly_int64 off0, off1; > tree base0, base1; > int equal = address_compare (cmp, TREE_TYPE (@2), @0, @1, base0, base1, > off0, off1, GENERIC); > } > (if (equal == 1) > (if (minmax == MIN_EXPR) > (if (known_le (off0, off1)) > @2 > (if (known_gt (off0, off1)) > @3)) > (if (known_ge (off0, off1)) > @2 > (if (known_lt (off0, off1)) > @3))))))) > and address_compare is a fairly large routine and uses equal_address_to > which is another quite large routine and we'd need to redo big chunks > of that code in constexpr.c. > Not using match.pd and fold-const.cc at all during constexpr evaluation > (except perhaps for folding of builtins) seems like a nice ultimate goal > (we would only optimize what we are required to and nothing else, at least > in the strict modes), but I'm afraid it would take several years to implement. > > Having another flag next to folding_initialize that would be used in > fold-const.c in the meantime looks fine to me, any suggestion on how to call > it? flag_unspecified_compare? Jason