From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112451 invoked by alias); 27 Apr 2015 15:01:28 -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 112398 invoked by uid 89); 27 Apr 2015 15:01:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Apr 2015 15:01:26 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by uk-mta-17.uk.mimecast.lan; Mon, 27 Apr 2015 16:01:22 +0100 Received: from e103246vm ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2015 16:01:23 +0100 From: "Wilco Dijkstra" To: "'Jeff Law'" , References: <000b01d013e5$4bc87010$e3595030$@com> <54878309.6070408@redhat.com> <000c01d0147c$dff88210$9fe98630$@com> <5488B150.1080704@redhat.com> In-Reply-To: <5488B150.1080704@redhat.com> Subject: RE: [PATCH] Fix IRA register preferencing Date: Mon, 27 Apr 2015 15:01:00 -0000 Message-ID: <000701d080fb$029b8e80$07d2ab80$@com> MIME-Version: 1.0 X-MC-Unique: NpRk-eT7SQ6uFCvfzBFDhg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-04/txt/msg01641.txt.bz2 > Jeff Law wrote: > On 12/10/14 06:26, Wilco Dijkstra wrote: > > > > If recomputing is best does that mean that record_reg_classes should not > > give a boost to the preferred class in the 2nd pass? > Perhaps. I haven't looked deeply at this part of IRA. I was relaying > my experiences with (ab)using the ira-reload callbacks to handle > allocation after splitting -- where getting the costs and classes > updated in a reasonable manner was clearly important to getting good > code. One could probably argue I should have kept testcases from that > work :-) >=20 >=20 > I don't understand > > what purpose this has - if the preferred class is from the first pass, = it > > is already correct, so all it does is boost the preferred class further. > > And if the preferred class is wrong (eg. after live range splitting), it > > will boost the incorrect class even harder, so in the end you never get > > a different class. > It may be historical from the old regclass code, not really sure. >=20 > > From what you're saying, recomputing seems best, and I'd be happy to s= ubmit > > a patch to remove all the preferred class code from record_reg_classes. > Recomputing certainly helped the cases I was looking at. > > > > However there is still the possibility the preferred class is queried b= efore > > the recomputation happens (I think that is a case Renlin fixed). Either= these > > should be faulted and fixed by forcing recomputation, or we need to pro= vide a > > correct preferred class. That should be a copy of the original class. > I believe I had copied the original classes, then recomputed them to > avoid any uninitialized memory reads and the like. But looking at the > old branch, I don't see the recomputation for classes (though I do see > it for costs). Of course all the backwards walk stuff isn't there > either, so there's clearly code I worked on extensively, but never > committed... Well, looking into this further it does look like the preferences are impro= ved during the 2nd pass (in particular fewer cases of the bad ALL_REGS preferen= ce that causes all the inefficient code), so it looks like recomputing prefere= nces is not beneficial and my original patch is the right fix for now. https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00829.html Wilco