From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by sourceware.org (Postfix) with ESMTPS id 00C5B3858D35 for ; Sun, 25 Jun 2023 06:36:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00C5B3858D35 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-xb34.google.com with SMTP id 3f1490d57ef6-bd6d9d7da35so2255972276.0 for ; Sat, 24 Jun 2023 23:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687674960; x=1690266960; 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=bBmZMJI6YStTxNwnp4hiCvjluZ7mHX/GiBdDlXHfuBs=; b=rWhcLaiowFqlMi9/C38UX73eKjmFbLyeI1wgOhal3TI27oMCXV54IxpWWx1DjlxNfr EPfYINgMojATrUNPCxJB+DTOBSDFv0Kh+P9M3D/w4a4QlLwF9Wd8PGnKdwltT+uTBrhW V4MoS9KB8f2jGhm0eeXxX59kDPnpOTfxnhTD1c+Ohpl0gEwCfCpWLXJ1qOq5UA9wZ39w yRm1+yQchZQPAN3J7eoabZDFLJ1OORC5o0tmBxIKPqpfJ1tgOxi8jnJ7qIQ9Z5I7svLG h4Jr0mYBa74aLmqxbhRYITs35nNYale5bRyH+rXLlgX8gXIeNYLttynLM+oYiskp636K y4ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687674960; x=1690266960; 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=bBmZMJI6YStTxNwnp4hiCvjluZ7mHX/GiBdDlXHfuBs=; b=cQ+ImuIrpH36KJtxFJojVXMB8UEHk+iarvJE/YziTas8X+dugjaip4HAE6W8wqSsYl bKXPoWdFdN1AMDiVbUJvVMCkkMURyjgyA+FGv93knRw5Otfx0hxKwnRjnnhuWSa0Mh0q u8aIq5VPDx9IM7PAeYtVIZjz4uTVzMBtczzYUq3oWz7CGytBPq3nE9zErkVVCT9NjR2I rf86BHrLMMhSXtkZ4AkvDisLJS+hGOCl7cY3G+d7nFxm83VZbXleM1MJMk+hD/77r9OP Sq9gpRFfTLaD/265WFmmhvD5/mfoKQCbmY4YbBCDPkfvrvhguo/K82i/HSCPUsAUaYtx 92lg== X-Gm-Message-State: AC+VfDzzNbfeuJ26Zgl1SuhdOXOEfxV/qGTfx0TE+5b41flOnQ3m0CZh nhnkULthLHbzQbwMVBQQlIGsJMpWfo/m9Ak3Xgg= X-Google-Smtp-Source: ACHHUZ5ArINBtvsOlE4NmnIhtIuZoh7o+mE9uri39iFicNiC4esUTsIEHR7rPQwDmUKj0d4seLlwalYO8zx8HK1C0uU= X-Received: by 2002:a25:f605:0:b0:bc5:402a:ae6f with SMTP id t5-20020a25f605000000b00bc5402aae6fmr22441510ybd.19.1687674960278; Sat, 24 Jun 2023 23:36:00 -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: <460e0857-2ee9-d946-4067-9569fa767420@suse.com> From: Hongtao Liu Date: Sun, 25 Jun 2023 14:35:49 +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.9 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:25=E2=80=AFPM Jan Beulich wro= te: > > 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 name > >> selection it will want considering that this is applicable to certain > >> 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? > > 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 --=20 BR, Hongtao