From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 005F7385840F for ; Wed, 18 Aug 2021 23:12:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 005F7385840F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 17INB4Gf008602; Wed, 18 Aug 2021 18:11:04 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 17INB3j9008599; Wed, 18 Aug 2021 18:11:03 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 18 Aug 2021 18:11:03 -0500 From: Segher Boessenkool To: David Edelsohn Cc: Michael Meissner , GCC Patches , Bill Schmidt , Peter Bergner , Will Schmidt Subject: Re: [PATCH] Move xx* builtins to vsx.md. Message-ID: <20210818231103.GM1583@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, MEDICAL_SUBJECT, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 23:12:15 -0000 On Wed, Aug 18, 2021 at 04:42:42PM -0400, David Edelsohn wrote: > I wanted to give Segher a chance to comment on the structure. I think the current vector.md / altivec.md / vsx.md / rs6000.md division is artificial at best. Most of the basic (movement etc.) things are in rs6000.md (and all should be), but nothing else is clear. The name "altivec.md" suggests it is only for the very old things, but it is not used that way, and that it untenable anyway: we have more recent insns to plug holes in that (for example 64-bit integer support), so it arguably is not just for that. Using it for instructions that only work on the high 32 VSRs (i.e. the VRs) is quite artificial as well -- sometimes there are equivalent insns for the other 32 VSRs already, sometimes it is just because of opcode scarcity, sometimes it is because it is for the slow vector unit only (but those seem to live in rs6000.md and crypto.md anyway). Maybe we should give up on dividing these things, and put both in one file, say vector.md? Segher