From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id F09CA3858408 for ; Mon, 29 Jul 2024 16:34:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F09CA3858408 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org F09CA3858408 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722270878; cv=none; b=F/uh/+uxr9aaalLFHL7qNsP9bFx25es+ZaWSVxxZ/RbGubl28kTLTRYg1Akl5TXNEm9L0EwRpWQSjqZw6+dKXrbDCFeIywac9Q4aqwoyaCvyjoBEhzGe7r2Z+zU2eTedrbPupTPIUf/PDzab8YxkCmkFK38MM49HlodfWRPbjFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722270878; c=relaxed/simple; bh=D6p3q3ux7M73NH9h6oIOSHrl0peWt0/BYpYRW66dZ6I=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=MFqdQutHRLt63AaW5ItfPZ6T3cF1XB4vn9tly6MUydsuH6PxVf6D0eRL4W/GXqiTgUtHQF4+p+BTBMGJ7ajJTA7Y9icSQUj/i3VeaOZrzY4vlTRSGml82+z4xwkN4301CNpzZ7J/5xAIUVKmJ3fqcNUAONZOArxVOZrJrxaopY8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 40C761007; Mon, 29 Jul 2024 09:35:02 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 05C113F766; Mon, 29 Jul 2024 09:34:35 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener ,Jakub Jelinek , gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Cc: Jakub Jelinek , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 1/3] Add TARGET_MODE_CAN_TRANSFER_BITS In-Reply-To: (Richard Biener's message of "Mon, 29 Jul 2024 15:35:47 +0200 (CEST)") References: <19289.124072908144101259@us-mta-160.us.mimecast.lan> <30202o85-1p56-91qr-r983-9snq2n0072o3@fhfr.qr> Date: Mon, 29 Jul 2024 17:34:34 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Biener writes: > On Mon, 29 Jul 2024, Jakub Jelinek wrote: >> And, for the GET_MODE_INNER, I also meant it for Aarch64/RISC-V VL vectors, >> I think those should be considered as true by the hook, not false >> because maybe_ne. > > I don't think relevant modes will have size/precision mismatches > and maybe_ne should work here. Richard? Yeah, I think that's true for AArch64 at least (not sure about RVV). One wrinkle is that VNx16BI (every bit of a predicate) is technically suitable for memcpy, even though it would be a bad choice performance-wise. But VNx8BI (every even bit of a predicate) wouldn't, since the odd bits are undefined on read. Arguably, this means that VNx8BI has the wrong precision, but like you say, we don't (AFAIK) support bitsize != precision for vector modes. Instead, the information that there is only one meaningful bit per boolean is represented by having an inner mode of BI. Both VNx16BI and VNx8BI have an inner mode of BI, which means that VNx8BI's precision is not equal the its nunits * its unit precision. So I suppose: maybe_ne (GET_MODE_BITSIZE (mode), GET_MODE_UNIT_PRECISION (mode) * GET_MODE_NUNITS (mode)) would capture this. Targets that want a vector bool mode with 2 meaningful bits per boolean are expected to define a 2-bit scalar boolean mode and use that as the inner mode. So I think the condition above would (correctly) continue to allow those. Thanks, Richard