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 0E65D3858D32 for ; Mon, 8 Apr 2024 12:43:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0E65D3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0E65D3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712580233; cv=none; b=bTDzzcyWZ098Za+JrzIfEpHONTYxPoxhExlxPB9PETtEJQxgtsOB5YbVmcN8ACX3wPXPeBEm5k0srM/W9eMia8YwyUeoRPC4ZKaCAzHWcwRisvmJpzibi4ygQLdWGlpuKRtrI9oB9HqRpwD1rG94o0mvpeNOQH9Um2XqkNRBDAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712580233; c=relaxed/simple; bh=iKzPO65uoHP6Mr81AIgg3i+W4DjYJOodV8iapmsE7n4=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Lj5hUsl4PfeuppQcxdl5mwScIj9Ch93L6f+IC+U4t0pqII7yMJ/Vzyx2A7GTSbhaz5750j46nuoY84V1JHBzoctwhHWhfybkrvrWRzmGu3V/MqBlr5HCGbLCCz1kIPG22m/tb9bwp01E1eFIROqvXifEaQlzGHb58sWe7tPcb18= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712580231; 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=XOZmXDkn+koDaJTrY2elBSNWr91v7l5VpDVTRO/uUik=; b=cUOLvBF577q73TcRO5hmnjhnWo1QJebZQzgPLMO857m9gs6Na+Bt4t9vvEAlOqYQP7/vyO TplE61n4/qeUCkh7sgpnDrsPt+3rPe7fxIMIqpvMqPSmpWq9t12iFEvRuTfhPwX1hydB8M s2cslwQXfTDlg1cefuQsbGg3uSu1QwQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-H1wzR8QWN--jTiVVusTFIw-1; Mon, 08 Apr 2024 08:43:48 -0400 X-MC-Unique: H1wzR8QWN--jTiVVusTFIw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id ABB43806626; Mon, 8 Apr 2024 12:43:47 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7103140AE782; Mon, 8 Apr 2024 12:43:47 +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 438ChP6T2585950 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 8 Apr 2024 14:43:25 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 438ChPvY2585949; Mon, 8 Apr 2024 14:43:25 +0200 Date: Mon, 8 Apr 2024 14:43:25 +0200 From: Jakub Jelinek To: "Jiang, Haochen" Cc: Hongtao Liu , "gcc-patches@gcc.gnu.org" , "Liu, Hongtao" , "ubizjak@gmail.com" Subject: Re: [PATCH] i386: Fix aes/vaes patterns [PR114576] Message-ID: Reply-To: Jakub Jelinek References: <20230418071851.4192579-1-haochen.jiang@intel.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 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=-4.2 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 Mon, Apr 08, 2024 at 12:33:39PM +0000, Jiang, Haochen wrote: > Sorry for the late response since I am on vacation for now. > > > As the following testcase shows, the above change was incorrect. > > > > Using aes isa for the second alternative is obviously wrong, aes is enabled > > whenever -maes is, regardless of -mavx or -mno-avx, so the above change > > means that for -maes -mno-avx RA can choose, either it matches the first > > alternative with the dup operand, or it matches the second one (but that > > is of course wrong because vaesenc VEX encoded insn needs AES & AVX CPUID). > > When I wrote that patch, I suppose it will never match the second one when > AVX is not enabled because it will immediately drop to the first one so the > second one is automatically AES && AVX, which is tricky here. Before the -mvaes changes the alternatives were noavx,avx isa and so clearly it was either the first alternative is the solely available, or the second, depending on TARGET_AVX. But with noavx,aes on the first alternative is enabled only for !TARGET_AVX, but the second one whenever TARGET_AES, which is both if !TARGET_AVX and TARGET_AVX. So, the RA is free to consider both alternatives, and because the first one is more restrictive (requires output matching input), if there is a match between those, it will use the first alternative, but if there isn't, it will happily use the second alternative. > LLVM always had less restrictions on ISA under such circumstances, I would like to > stick to how SDM did when implementing that, which is a little conservative. > > However, I am also ok with VAES implying AES if there is no real HW that has > VAES w/o AES to reduce complexity in this scenario. I'm fine with -mvaes not implying -maes, just want to mention that it is fairly user visible thing and so we shouldn't be changing it after deciding if we do it one way or another. Now, I thought -mvaes was added in GCC 14, but it has been around for a few years, so that means it is likely a bad idea to change it now. Jakub