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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id F0E403857818 for ; Thu, 29 Oct 2020 11:02:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org F0E403857818 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-60-Y4RRmp-eMJiPehpJuMrk-w-1; Thu, 29 Oct 2020 07:02:02 -0400 X-MC-Unique: Y4RRmp-eMJiPehpJuMrk-w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0941E10E218E; Thu, 29 Oct 2020 11:02:01 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-188.ams2.redhat.com [10.36.113.188]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9A71610013DB; Thu, 29 Oct 2020 11:02:00 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 09TB1vNf872772 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 29 Oct 2020 12:01:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 09TB1uPp872771; Thu, 29 Oct 2020 12:01:56 +0100 Date: Thu, 29 Oct 2020 12:01:56 +0100 From: Jakub Jelinek To: Hongtao Liu via Gcc-patches , Vladimir Makarov , Hongtao Liu , dcb314@hotmail.com, richard.sandiford@arm.com Subject: Re: [PATCH][PR target/97540] Don't extract memory from operand for normal memory constraint. Message-ID: <20201029110156.GD3788@tucnak> Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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=-6.3 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 29 Oct 2020 11:02:07 -0000 On Tue, Oct 27, 2020 at 11:13:21AM +0000, Richard Sandiford via Gcc-patches wrote: > Sorry to stick my oar in, but I think we should reconsider the > bcst_mem_operand approach. It seems like these patches (and the > previous one) are fighting against the principle that operands > cannot be arbitrary expressions. Many operands already are fairly complex expressions, so it is unclear how this changes that. And LRA etc. already handles SUBREGs of MEM which is kind of similar to this. > This kind of thing was attempted long ago (even before my time!) > for SIGN_EXTEND on MIPS. It ended up causing more problems than > it solved and in the end it had to be taken out. I'm worried that > we might end up going through the same cycle again. > > Also, this LRA code is extremely performance-sensitive in terms > of compile time: it's often at the top or near the top of the profile. > So adding calls to new functions like extract_mem_from_operand for > a fairly niche case probably isn't a good trade-off. It can be just an inline function that looks through just the target selected rtxes rather than arbitrary ones (derived from *.md properties or something). > I think we should instead find a nice(?) syntax for generating separate > patterns for the two bcst_vector_operand alternatives from a single > .md pattern. That would fit the existing model much more closely. That would result in thousands of new patterns, I'm not sure it is a good idea. Pretty much all AVX512* instructions allow those. Jakub