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 41E41388C03D for ; Sat, 6 Mar 2021 10:34:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 41E41388C03D 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-402-t8mRDpeUNemqlqWOcY02QQ-1; Sat, 06 Mar 2021 05:34:42 -0500 X-MC-Unique: t8mRDpeUNemqlqWOcY02QQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2EF811005415; Sat, 6 Mar 2021 10:34:41 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-45.ams2.redhat.com [10.36.112.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BA6B760BE5; Sat, 6 Mar 2021 10:34:40 +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 126AYb7c3947022 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 6 Mar 2021 11:34:38 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 126AYaRb3947021; Sat, 6 Mar 2021 11:34:36 +0100 Date: Sat, 6 Mar 2021 11:34:36 +0100 From: Jakub Jelinek To: Uros Bizjak , hjl.tools@gmail.com Cc: Jeff Law , Kirill Yukhin , "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] i386: Fix some -mavx512vl -mno-avx512bw bugs [PR99321] Message-ID: <20210306103436.GP745611@tucnak> Reply-To: Jakub Jelinek References: <20210305205058.GN745611@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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_LOW, 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: Sat, 06 Mar 2021 10:34:49 -0000 On Sat, Mar 06, 2021 at 11:19:15AM +0100, Uros Bizjak wrote: > > We already have Yw constraint which is equivalent to v for > > -mavx512bw -mavx512vl and to nothing otherwise, so for > > the instructions that need both we need to use xYw and > > v for modes that don't need that. > > Perhaps we should introduce another Y... constraint to return correct > SSE regset based on TARGET_... flags, instead of using compound xYw? I > think that introducing new constraint is the established approach we > should follow. The new mode_attr looks OK to me. One possibility would be to change the meaning of Yw, because it is an internal undocumented constraint and all uses in GCC currently use it as xYw: constraints.md:(define_register_constraint "Yw" mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw") mmx.md: (match_operand:V4HI 1 "register_mmxmem_operand" "ym,xYw") mmx.md: [(set (match_operand:V4HI 0 "register_operand" "=y,xYw") mmx.md: (match_operand:SI 1 "register_operand" "0,xYw"))))] Would that be ok? If not, I'll add (define_register_constraint "Yl" "TARGET_AVX512BW && TARGET_AVX512VL ? ALL_SSE_REGS : TARGET_SSE ? SSE_REGS : NO_REGS" "@internal Any EVEX encodable SSE register (@code{%xmm0-%xmm31}) for AVX512BW with TARGET_AVX512VL target, otherwise any SSE register.") Jakub