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.129.124]) by sourceware.org (Postfix) with ESMTPS id 534E23858D28 for ; Tue, 22 Aug 2023 15:01:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 534E23858D28 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=1692716507; 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:in-reply-to:in-reply-to: references:references; bh=thgFItwudCqCp7+DN/PmFmRpEsVw4Gr5EIq5O2WXjrM=; b=iigXamspHgh8IkEHE+Dkxg2ZVrHgW+UMIBsMErtV/nnHGHE4zh4fbobmg++fTsTHGZv+1Q m3PNRkBWJ9T0MWELGGnMCfI63MasaVQjtIGGmnVON97yklmmVnYojUVqMvxpM+vdtopt7f 9ha9Xgm1jIiE8ePUwRMYg7xG5lESscU= 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-651-iejDFEqrNMiQvXIDViGxTA-1; Tue, 22 Aug 2023 11:01:44 -0400 X-MC-Unique: iejDFEqrNMiQvXIDViGxTA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0390E85D06E; Tue, 22 Aug 2023 15:01:44 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.225.165]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B434F140E96F; Tue, 22 Aug 2023 15:01:43 +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 37MF1fXN2442984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 22 Aug 2023 17:01:42 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37MF1fq12442983; Tue, 22 Aug 2023 17:01:41 +0200 Date: Tue, 22 Aug 2023 17:01:41 +0200 From: Jakub Jelinek To: Hongtao Liu Cc: Richard Biener , "Jiang, Haochen" , ZiNgA BuRgA , "gcc-patches@gcc.gnu.org" Subject: Re: Intel AVX10.1 Compiler Design and Support Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 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.4 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_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 Tue, Aug 22, 2023 at 10:35:55PM +0800, Hongtao Liu wrote: > Let's assume there's no detla now, AVX10.1-512 is equal to > AVX512{F,VL,BW,DQ,CD,BF16,FP16,VBMI,VBMI2,VNNI,IFMA,BITALG, VPOPCNTDQ} > > other stuff. > > The current common/config/i386/i386-common.cc OPTION_MASK_ISA*SET* would be > > like now, except that the current AVX512* sets imply also EVEX512/whatever > > it will be called, that option itself enables nothing (or TARGET_AVX512F), > > and unsetting it doesn't disable all the TARGET_AVX512*. > > -mavx10.1 would enable the AVX512* sets without EVEX512/whatever. > So for -mavx512bw -mavx10.1-256, -mavx512bw will set EVEX512, but > -mavx10.1-256 doesn't clear EVEX512 but just enable all AVX512* sets?. > then the combination basically is equal to AVX10.1-512(AVX512* sets + > EVEX512) > If this is your assumption, yes, there's no need for TARGET_AVX10_1. I think that would be my expectation. -mavx512bw currently implies 512-bit vector support of avx512f and avx512bw, and with -mavx512{bw,vl} also 128-bit/256-bit vector support. All pre-AVX10 chips which do support AVX512BW support 512-bit vectors. Now, -mavx10.1 will bring in also vl,dq,cd,bf16,fp16,vbmi,vbmi2,vnni,ifma,bitalg,vpopcntdq as you wrote which weren't enabled before, but unless there is some existing or planned CPU which would support 512-bit vectors in avx512f and avx512bw ISAs and only support 128/256-bit vectors in those dq,cd,bf16,fp16,vbmi,vbmi2,vnni,ifma,bitalg,vpopcntdq isas, I think there is no need to differentiate further; the only CPUs which will support both what -mavx512bw and -mavx10.1 requires will be (if there is no delta) either CPUs with 128/256/512-bit vector support of those f,vl,bw,dq,cd,...vpopcntdq ISAs, or AVX10.1-512 ISAs. -mavx512vl -mavx512bw -mno-evex512 -mavx10.1-256 would on the other side disable all 512-bit vector instructions and in the end just mean the same as -mavx10.1-256. For just -mavx512bw -mno-evex512 -mavx10.1-256 the question is if that -mno-evex512 turns off also avx512bw/avx512f because avx512vl isn't enabled at that point during processing, or if we do that only at the end as a special case. Of course, in this exact case there is no difference, because -mavx10.1-256 turns that back on. But it would make a difference on -mavx512bw -mno-evex512 -mavx512vl (when processed right away would disable AVX512BW (because VL isn't on) and in the end enable VL,F including EVEX512, or be equivalent to just -mavx512bw -mavx512vl if processed at the end, because -mavx512vl implied -mevex512 again. Jakub