From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8708 invoked by alias); 10 Dec 2014 13:26:30 -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 8695 invoked by uid 89); 10 Dec 2014 13:26:29 -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: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 10 Dec 2014 13:26:28 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Wed, 10 Dec 2014 13:26:25 +0000 Received: from e103246vm ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Dec 2014 13:26:23 +0000 From: "Wilco Dijkstra" To: "'Jeff Law'" , References: <000b01d013e5$4bc87010$e3595030$@com> <54878309.6070408@redhat.com> In-Reply-To: <54878309.6070408@redhat.com> Subject: RE: [PATCH] Fix IRA register preferencing Date: Wed, 10 Dec 2014 13:26:00 -0000 Message-ID: <000c01d0147c$dff88210$9fe98630$@com> MIME-Version: 1.0 X-MC-Unique: 114121013262500301 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-12/txt/msg00911.txt.bz2 > Jeff Law wrote: > On 12/09/14 12:21, Wilco Dijkstra wrote: > > With the fix it uses a floating point register as expected. Given a sim= ilar issue in > > https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html, would it not = be better to change > the > > initialization values of reg_pref to illegal register classes so this k= ind of issue can be > trivially > > found with an assert? Also would it not be a good idea to have a single= register copy > function that > > ensures all data is copied? > But there are other times when you really don't want to copy, say when > the original had a small class, but the copy can go into a larger class. >=20 > I banged my head on this when I was doing similar work on range > splitting a few years back and ended up recomputing the preferred and > alternate class information. That was much better than copying the > classes. If recomputing is best does that mean that record_reg_classes should not give a boost to the preferred class in the 2nd pass? 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.=20 And if the preferred class is wrong (eg. after live range splitting), it=20 will boost the incorrect class even harder, so in the end you never get=20 a different class. > I pondered heuristics to expand the preferred class, but never > implemented anything IIRC. A trivial heuristic would be to bump to the > next larger class if the given class was a singleton, otherwise copy the > class. >=20 > The obvious counter to that heuristic is an allocno that has two ranges > (or N ranges) where we would prefer a different singleton class for each > range. In fact, I'm pretty sure I ran into this kind of situation and > that led me down the "just recompute it" path. >=20 > I'd hazard a guess that the simple heuristic would do better than what > we're doing now with GENERAL_REGS though or what you're doing with copyin= g. >From what you're saying, recomputing seems best, and I'd be happy to submit a patch to remove all the preferred class code from record_reg_classes. However there is still the possibility the preferred class is queried before the recomputation happens (I think that is a case Renlin fixed). Either the= se should be faulted and fixed by forcing recomputation, or we need to provide= a=20 correct preferred class. That should be a copy of the original class. Wilco