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 72FAC385B528 for ; Mon, 6 Mar 2023 16:19:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 72FAC385B528 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678119543; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=BwBYQKUCvTCsyhT6MBxnimkBgkWPITbFVLhh0v65pfM=; b=P2afE96a5BNPBMH1bxOzqBbZWuhyIpC4eJGkhhVT2pQ/g3Yz/plKMGD5SYp64rveTjVUSh z5RjcKFwciLVG0l2/1pHlFxh/hlbkgDfuAyMYak8WZCeHCFVNlExG2ZqQDb+Ob3obv9nQr saPtUhLy5a4DgBTfsLbsQCGvGkVp3o0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-194-q5Y-pOK-OdaMX0x8flR82w-1; Mon, 06 Mar 2023 11:19:00 -0500 X-MC-Unique: q5Y-pOK-OdaMX0x8flR82w-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id CC85C18A6460; Mon, 6 Mar 2023 16:18:57 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 86356C16029; Mon, 6 Mar 2023 16:18:56 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 326GIrR3496958 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 6 Mar 2023 17:18:53 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 326GIp3W496957; Mon, 6 Mar 2023 17:18:51 +0100 Date: Mon, 6 Mar 2023 17:18:50 +0100 From: Jakub Jelinek To: Segher Boessenkool , Jeff Law via Gcc-patches , Tamar Christina , Roger Sayle , Jeff Law , richard.sandiford@arm.com Subject: Re: [PATCH] combine: Try harder to form zero_extends [PR106594] Message-ID: Reply-To: Jakub Jelinek References: <000c01d94ec7$a6921430$f3b63c90$@nextmovesoftware.com> <20230304221749.GK25951@gate.crashing.org> <3b1ed616-5d90-7a66-63b5-bdb5e320eebf@gmail.com> <20230306135850.GN25951@gate.crashing.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Mar 06, 2023 at 03:08:00PM +0000, Richard Sandiford via Gcc-patches wrote: > Segher Boessenkool writes: > > On Mon, Mar 06, 2023 at 12:47:06PM +0000, Richard Sandiford wrote: > >> How about the patch below? > > > > What about it? What would make it any better than the previous? > > It does what Jeff suggested in the quoted message: work within the existing > extract/make_compound_operation scheme rather than try to opt out of it. That still feels like it could be risky in stage4, affecting various other FEs which would be expecting ANDs in their patterns instead of *_EXTEND, no? So, at least we'd need something like Segher ran to test it on various targets on Linux kernel (but would be really nice to get also i?86/x86_64). If it were on the aarch64 side just one pattern, I'd suggest a pre-reload splitter, but unfortunately the sign extends (and zero extends?) are handled in legitimate address hook. Also, I see nonzero_bits only called in rs6000's combine splitter and s390'x canonicalize_comparison target hook, nowhere else in the backends, so I think using it outside of the combiner isn't desirable. Could we have a target hook to canonicalize memory addresses for combiner, like we have that targetm.canonicalize_comparison ? Jakub