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 6BDA93858001 for ; Tue, 24 Nov 2020 13:00:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6BDA93858001 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-224-MQs0eiIaPrC0-mivJIiSHw-1; Tue, 24 Nov 2020 08:00:49 -0500 X-MC-Unique: MQs0eiIaPrC0-mivJIiSHw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9323C106F8DA; Tue, 24 Nov 2020 13:00:47 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-127.ams2.redhat.com [10.36.113.127]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F3BF61F048; Tue, 24 Nov 2020 13:00:17 +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 0AOD0EI7458849 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 24 Nov 2020 14:00:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 0AOD0BLD458848; Tue, 24 Nov 2020 14:00:11 +0100 Date: Tue, 24 Nov 2020 14:00:10 +0100 From: Jakub Jelinek To: Hongtao Liu Cc: Jeff Law , GCC Patches Subject: Re: [PATCH][PR target/97642] Fix incorrect replacement of vmovdqu32 with vpblendd. Message-ID: <20201124130010.GT3788@tucnak> Reply-To: Jakub Jelinek References: <8643c8d6-5e88-0bf0-b174-cc56e4bcb024@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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.0 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_H4, 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: Tue, 24 Nov 2020 13:00:58 -0000 On Tue, Nov 24, 2020 at 10:36:49AM +0800, Hongtao Liu via Gcc-patches wrote: > > > * gcc.target/i386/pr97642-2.c: New test. > > So in the BZ Jakub asked for the all-ones mask case to be specially > > handled to emit a normal load. I don't see where we're handling that. > > ISTM that we'd want a test for that too. Right? > > > > all-ones mask would be simplified to a simple load but with unspec in > set_src and would be handled by the following > > +(define_insn_and_split "*_load" > + [(set (match_operand:V48_AVX512VL 0 "register_operand") > + (unspec:V48_AVX512VL > + [(match_operand:V48_AVX512VL 1 "memory_operand")] > + UNSPEC_MASKLOAD))] > + "TARGET_AVX512F" > + "#" > + "&& 1" > + [(set (match_dup 0) (match_dup 1))]) It is certainly good to have these insns and splitters, but the reason I think it is very much desirable to handle this during expansion too is to avoid creating the UNSPECs in the very common case where either already from the user, or from all the GIMPLE optimizations the mask is optimized into all ones. The UNSPECs then can prevent various optimizations before splitting is performed, because generic RTL optimizers don't know anything about what it does. While for all ones mask it is easily expressible in RTL by having the most simple RTL for that, plain load. Jakub