From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97550 invoked by alias); 14 Jul 2015 13:12:40 -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 97516 invoked by uid 89); 14 Jul 2015 13:12:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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 (AES256-SHA encrypted) ESMTPS; Tue, 14 Jul 2015 13:12:38 +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 t6EDCZEI029208; Tue, 14 Jul 2015 08:12:35 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id t6EDCYwu029207; Tue, 14 Jul 2015 08:12:34 -0500 Date: Tue, 14 Jul 2015 13:12:00 -0000 From: Segher Boessenkool To: Jeff Law Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH, RFC] combine: Don't create insv insns unless HAVE_insv Message-ID: <20150714131234.GD17453@gate.crashing.org> References: <6dd6eab124b41ccbae427674b36432a071fd7891.1436707794.git.segher@kernel.crashing.org> <55A49514.2040601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A49514.2040601@redhat.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg01151.txt.bz2 On Mon, Jul 13, 2015 at 10:50:28PM -0600, Jeff Law wrote: > On 07/12/2015 07:56 AM, Segher Boessenkool wrote: > >Currently combine tries to make assignments to bitfields (of a register) > >whenever it can. If the target has no insv pattern, the result will not > >ever match (if the MD is sane at all). Doing insv on registers generates > >worse code than what you get if you express things directly (with and/ior), > >so many targets do not _want_ to have insv patterns. > > > >This patch changes combine to not generate insv patterns if the target > >does not have any. > > > >Bootstrapped and regression checked on powerpc64-linux (with and without > >insv patterns there). Also built on many other targets, for many months. > > > >I'm vaguely aware there have been changes to extzv etc. so there now are > >extzv; I'll investigate if that means anything for insv as well. > >It's also a new #ifdef HAVE_xxx. But we're not clean there yet so I hope > >to get away with that ;-) > > > >Comments? Complaints? > Well, I'd rather avoid the #ifdef. Just because we aren't clean yet > doesn't mean we need to introduce more stuff to clean up later. This patch is very old, from long before the HAVE_* conversion ;-) I'll clean it up, the insv needs handling anyway. > It'd also be nice to have a testcase or two. Guessing they'd be target > dependent, but that's OK with me. I can make some for the powerpc insert things, when that goes in. What you need to test is that combine does *not* create insv from thin air, so that it _can_ create other things. It is pretty hard to test if things are *not* done :-) Segher