From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Idgz=CD=arm.com=richard.sandiford@sourceware.org>
Received: from foss.arm.com (foss.arm.com [217.140.110.172])
	by sourceware.org (Postfix) with ESMTP id DD5DC38582B7
	for <gcc-patches@gcc.gnu.org>; Thu, 15 Jun 2023 09:58:38 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DD5DC38582B7
Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com
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 AECA31FB;
	Thu, 15 Jun 2023 02:59:22 -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 95D063F71E;
	Thu, 15 Jun 2023 02:58:37 -0700 (PDT)
From: Richard Sandiford <richard.sandiford@arm.com>
To: Andrew Stubbs <ams@codesourcery.com>
Mail-Followup-To: Andrew Stubbs <ams@codesourcery.com>,Richard Biener <rguenther@suse.de>,  <gcc-patches@gcc.gnu.org>,  Jan Hubicka <hubicka@ucw.cz>,  <hongtao.liu@intel.com>,  <kirill.yukhin@gmail.com>, richard.sandiford@arm.com
Cc: Richard Biener <rguenther@suse.de>,  <gcc-patches@gcc.gnu.org>,  Jan Hubicka <hubicka@ucw.cz>,  <hongtao.liu@intel.com>,  <kirill.yukhin@gmail.com>
Subject: Re: [PATCH 3/3] AVX512 fully masked vectorization
References: <8aab0039-56a5-5bb8-e58a-29f13a9a6737@codesourcery.com>
	<DA5221DD-8F3C-47A3-821D-8CB09DA5E60B@suse.de>
	<378905b9-2383-d564-1c91-2c6b1e06629d@codesourcery.com>
Date: Thu, 15 Jun 2023 10:58:36 +0100
In-Reply-To: <378905b9-2383-d564-1c91-2c6b1e06629d@codesourcery.com> (Andrew
	Stubbs's message of "Thu, 15 Jun 2023 10:26:33 +0100")
Message-ID: <mpty1klavxv.fsf@arm.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-21.6 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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: <gcc-patches.gcc.gnu.org>

Andrew Stubbs <ams@codesourcery.com> writes:
> One 
> comment: building a vector constant {0, 1, 2, 3, ...., 63} results in a 
> very large entry in the constant pool and an unnecessary memory load (it 
> literally has to use this sequence to generate the addresses to load the 
> constant!) Generating the sequence via VEC_SERIES would be a no-op, for 
> GCN, because we have an ABI-mandated register that already holds that 
> value. (Perhaps I have another piece missing here, IDK?)

A constant like that should become a CONST_VECTOR in RTL, so I think
the way to handle it would be to treat such a CONST_VECTOR as a valid
immediate operand, including providing an alternative for it in the
move patterns.  const_vec_series_p provides a quick way to test.

Thanks,
Richard