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 44C023858D20 for ; Fri, 1 Sep 2023 09:20:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 44C023858D20 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=1693560046; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bSu2x91vhf2nf/nJRv1xbaE9Ot6ejINkjYwXzTxQjWk=; b=Qr0KoLhE8efEj6KXvuv/noJWg4HKoyo5AiwtNikcPVIolBYaklnKaxlAOESmL5zQX96k8k n80F8xTOUVQFJjsxZ1IQgOyEYqx0mEFJ6krBR/n5UYSl4cNnAHQKyHsp9nFkc04aWCQoaa zYi87mo0cZKvgqMlw5k4frfZASULI60= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-274-qymdXl5jP6KOyH09qULBRQ-1; Fri, 01 Sep 2023 05:20:43 -0400 X-MC-Unique: qymdXl5jP6KOyH09qULBRQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3AAD53C11C80; Fri, 1 Sep 2023 09:20:43 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C696C5CC06; Fri, 1 Sep 2023 09:20:42 +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 3819Kfdm303225 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 1 Sep 2023 11:20:41 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 3819Keku303224; Fri, 1 Sep 2023 11:20:40 +0200 Date: Fri, 1 Sep 2023 11:20:40 +0200 From: Jakub Jelinek To: Hongyu Wang Cc: Hongyu Wang , gcc-patches@gcc.gnu.org, hongtao.liu@intel.com, hubicka@ucw.cz Subject: Re: [PATCH 08/13] [APX EGPR] Handle GPR16 only vector move insns Message-ID: Reply-To: Jakub Jelinek References: <20230831082024.314097-1-hongyu.wang@intel.com> <20230831082024.314097-9-hongyu.wang@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,BODY_8BITS,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_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 Fri, Sep 01, 2023 at 05:07:53PM +0800, Hongyu Wang wrote: > Jakub Jelinek via Gcc-patches 于2023年8月31日周四 17:44写道： > > > > On Thu, Aug 31, 2023 at 04:20:19PM +0800, Hongyu Wang via Gcc-patches wrote: > > > For vector move insns like vmovdqa/vmovdqu, their evex counterparts > > > requrire explicit suffix 64/32/16/8. The usage of these instruction > > > are prohibited under AVX10_1 or AVX512F, so for AVX2+APX_F we select > > > vmovaps/vmovups for vector load/store insns that contains EGPR. > > > > Why not make it dependent on AVX512VL? > > I.e. if egpr_p && TARGET_AVX512VL, still use vmovdqu16 or vmovdqa16 > > and the like, and only if !evex_reg_p && egpr_p && !TARGET_AVX512VL > > fall back to what you're doing? > > I'm not sure if it is necessary, as on hardware there is no difference between > vmovdqu16/vmovups. If vmovups already has the capability to represent > EGPR why do we need to distinguish them under VL? On the Intel HW you're currently planning. Will that be the case for AMD as well? Some insns are documented to move float or double vectors while others integer vectors (of different element sizes). Or is vmovups with GPR32 at least encoded smaller than vmovdqu{16,32,64}? Jakub