From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) by sourceware.org (Postfix) with ESMTPS id B80173858C62 for ; Sun, 25 Jun 2023 06:41:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B80173858C62 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-yb1-xb35.google.com with SMTP id 3f1490d57ef6-bd729434fa0so2352446276.1 for ; Sat, 24 Jun 2023 23:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687675277; x=1690267277; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=S4ogTG2zkuOuw3ISrJhM/wgPGCWuFYAk3jrK5Yq1Wxk=; b=XGQVtON58Fl+rgfMAi7XZsZNrpf7+qxn477xfr+IgaUceg5zyfZTXIhOsnyk0y6a29 VuVZklkTsX6TqpkB9aznr/nGbW6mdu+K+MdMkMXli/m0xU2D0MDMdqUGlibT1xxa5nu1 DNzQqlHHId9Yn2eSMkEwt4LbuxWcvhkNgIjsXfrYz/AHzJvpmZkKvedL7QIhDRJbv/pP gwbuaKz9M1W3F8JjwMmFRQ+NVfoSVZHhLPT5/BkJboaQk8kO6jqcVAbD4i4A9gcck0f+ jHlLIOWXimmoYvpR0FLmSjyTWNqifM6CkT3zyT+t0hv7OLJFV7Hf6Ekd39bxMEBL6J+x cPPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687675277; x=1690267277; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=S4ogTG2zkuOuw3ISrJhM/wgPGCWuFYAk3jrK5Yq1Wxk=; b=k/SStU/N1kyFmtyQ/RqevQJQV4m1MlwgCTfypXtH9wmQnMyUvDOpHsBf24xYHeeCGA k4jO9QtTTfm2+1r4uQeF/r7fGzInTvvSoaJwfPxq5eXPV5TYOJM3mLdi6zqGfPbsI3+l /mLWN1W38af+zebOuUTpoPFLYatleIk4U2Cxxs5HuOZkwqSiO2a86UsVKGCVNHsSHrW/ vpgXWDQpMql5zwmrZKSxq+paGn1zGaIBWgC6Jnzz3vJPPcoHq/QBiyoXArvcRspE+n8d VgUOVwUcXPnVM4eD9AzRDWEXYAqiR6+0qpNGkAa6pIrsDlWaud/chtFvNM9E62AM564y K+WQ== X-Gm-Message-State: AC+VfDxCLWNhp+Qu+F0vrTD+c8cSJPASOQ/mFQIUrdqtIjlWlcIicm25 vB6tw/TzlGiXZNRAK3w1R4hVUi9E8l1prCgSj1JxtQFqs/8nhg== X-Google-Smtp-Source: ACHHUZ6fKRDh8ZhVGtZJBVnt2h+qyCoZ7uh884vvMgZFgsHKCchXFzWuzZXvXVYJ08D429JYiwoH+a1Df5wEpeO3R8E= X-Received: by 2002:a25:2d23:0:b0:bb8:bc76:d068 with SMTP id t35-20020a252d23000000b00bb8bc76d068mr24854299ybt.55.1687675277142; Sat, 24 Jun 2023 23:41:17 -0700 (PDT) MIME-Version: 1.0 References: <04f99abe-a563-d093-23b7-4abf0f91633d@suse.com> <0075f542-9dc0-33db-4cf9-cdd3ba502122@suse.com> <460e0857-2ee9-d946-4067-9569fa767420@suse.com> In-Reply-To: From: Hongtao Liu Date: Sun, 25 Jun 2023 14:41:06 +0800 Message-ID: Subject: Re: [PATCH 5/5] x86: yet more PR target/100711-like splitting To: Jan Beulich Cc: "gcc-patches@gcc.gnu.org" , Hongtao Liu , Kirill Yukhin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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 Sun, Jun 25, 2023 at 2:35=E2=80=AFPM Hongtao Liu wr= ote: > > On Sun, Jun 25, 2023 at 2:25=E2=80=AFPM Jan Beulich w= rote: > > > > On 25.06.2023 07:12, Hongtao Liu wrote: > > > On Wed, Jun 21, 2023 at 2:29=E2=80=AFPM Jan Beulich via Gcc-patches > > > wrote: > > >> > > >> --- > > >> For the purpose here (and elsewhere) bcst_vector_operand() (really: > > >> bcst_mem_operand()) isn't permissive enough: We'd want it to allow > > >> 128-bit and 256-bit types as well irrespective of AVX512VL being > > >> enabled. This would likely require a new predicate > > >> (bcst_intvec_operand()?) and a new constraint (BR? Bi?). (Yet for na= me > > >> selection it will want considering that this is applicable to certai= n > > >> non-calculational FP operations as well.) > > > I think so. > > > > Any preference towards predicate and constraint naming? > something like bcst_mem_operand_$suffiix, $suffix indicates the > pattern may use zmm instruction for 128/256-bit operand. > maybe just bcst_mem_operand_zmm? For constraint, maybe we can reuse Br, relax Br to match bcst_mem_operand_z= mm. For those original patterns with bcst_mem_operand, it should be ok since it's already guarded by the predicate, the constraint must be valid. > > > > > Plus I think there's a more general question behind this: A new > > predicate / constraint pair is likely just one way of dealing > > with the issue. Another would appear to be to remove the > > restriction of 128- and 256-byte types when AVX512VL is not > > enabled, but AVX512F is. While that would require touching a > > lot of insn constraints, it looks as if lifting that restriction > > would "merely" require much wider use of Yv where v is used > > right now. But of course I may well be unaware of (some of) the > > reasons why that restriction was put in place in the first place > > (it can't really be the lack of suitable move insns, as those > > can be synthesized by using e.g. vextract{32,64}x4). > Also be careful of SIMD Floating-Point Exception if we use the zmm > version for those arithmetic instructions, the upper bits need to be > explicitly cleared for 128/256-bit operand. > For pternlog or other logic instructions, it's ok since there's no > SIMD Floating-Point Exception for such instructions. > > > > > Jan > > > > -- > BR, > Hongtao --=20 BR, Hongtao