From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30188 invoked by alias); 16 Jun 2017 21:30:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29953 invoked by uid 89); 16 Jun 2017 21:30:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=super X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Jun 2017 21:30:48 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id v5GLUngT024331; Fri, 16 Jun 2017 16:30:49 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id v5GLUm20024330; Fri, 16 Jun 2017 16:30:48 -0500 Date: Fri, 16 Jun 2017 21:30:00 -0000 From: Segher Boessenkool To: Michael Meissner , GCC Patches , David Edelsohn , Bill Schmidt Subject: Re: [PATCH, rev 2] PR target/79799, Add vec_insert of V4SFmode on PowerPC ISA 3.0 (power9) Message-ID: <20170616213047.GJ16550@gate.crashing.org> References: <20170615000158.GA11033@ibm-tiger.the-meissners.org> <20170615233938.GA15195@ibm-tiger.the-meissners.org> <20170616021027.GA2916@ibm-tiger.the-meissners.org> <20170616195246.GH16550@gate.crashing.org> <20170616202658.GA2150@ibm-tiger.the-meissners.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170616202658.GA2150@ibm-tiger.the-meissners.org> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01242.txt.bz2 On Fri, Jun 16, 2017 at 04:26:58PM -0400, Michael Meissner wrote: > > > + "&& reload_completed" > > > > I still don't think it is such a good idea to do all of this not until > > after reload. It does of course allow you to play tricks with changing > > register mode at will, like you do ;-) > > The problem is MODES_TIEABLE_P. V4S{I,F}mode and SImode cannot be tied > together (i.e. use gen_lowpart to change the mode and use a SUBREG). So after > reload, we can just use gen_rtx_REG (...) to change the register type, but > before reload, by creating the SUBREG, it can lead to various aborts if rtl > checking is turned on. That sounds like a problem elsewhere? Hrm. > > All these unspecs are a similar problem: the RTL optimisers cannot do > > much at all with it. > > I don't think there is a good way to represent a vec_insert. And vec_extract > can't represent a variable extract either. Yeah. But especially for all this lane shuffling etc. the generic optimisers could do a good job, if only they knew how. Maybe we need some new RTL codes. > > > + [(set_attr "type" "vecperm") > > > Is that a good type for this? I think the convert is more expensive > > than the permutes? If so, that would be better (of course it only > > matters for sched1, not super important). > > I generally use the type of the last insn. I am open to other suggestions. It should describe the resulting insns as a whole. Picking the type of the most expensive insn is often a reasonable approximation; for integer insns "two" or "three" can be okay. I don't think we can do much better currently. Segher