From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5857 invoked by alias); 13 Jul 2010 20:43:36 -0000 Received: (qmail 5849 invoked by uid 22791); 13 Jul 2010 20:43:35 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Jul 2010 20:43:29 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6DKhJdI024272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Jul 2010 16:43:19 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6DKhJoI027043; Tue, 13 Jul 2010 16:43:19 -0400 Received: from [172.17.76.3] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6DKhHqw015759; Tue, 13 Jul 2010 16:43:18 -0400 Message-ID: <4C3CCFE4.3030203@redhat.com> Date: Tue, 13 Jul 2010 20:43:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Bernd Schmidt CC: GCC Patches Subject: Re: Patch 10/9: track subwords of DImode allocnos References: <4C1B7BC0.7010803@codesourcery.com> <4C1F9B96.4030007@codesourcery.com> In-Reply-To: <4C1F9B96.4030007@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2010-07/txt/msg01099.txt.bz2 On 06/21/10 11:04, Bernd Schmidt wrote: > So here's the scary part. This adds ALLOCNO_NUM_OBJECTS and the > possibility that it may be larger than 1. Currently, it only tries to > do anything for two-word (i.e. DImode) allocnos; it should be possible > (and even relatively easy) to extend, but I'm not sure it's worthwhile. > Whether even this version is worthwhile is for others to decide. > > I should explain what I've done with the conflict handling. Given two > DImode allocnos A and B with halves Ah, Al, Bh and Bl, we can encounter > four different conflicts: AhxBl, AhxBh, AlxBh and AlxBl. Of these, only > three are meaningful: AhxBh and AlxBl can be treated equivalently in > every place I found. This reduces the number of ways two such allocnos > can conflict to 3, and I've implemented this (as "conflict > canonicalization") by recording an AlxBl conflict instead of a AhxBh > conflict if one is found. This is meaningful for functions like > setup_allocno_left_conflicts_size: each of these three conflicts reduces > the number of registers available for allocation by 1. > > There are some places in IRA that use conflict tests to determine > whether two allocnos can be given the same hard register; in these cases > it is sufficient to test the low-order objects for conflicts (given the > canonicalization described above). Any other type of conflict would not > prevent the allocnos from being given the same hard register (assuming > that both will be assigned two hard regs). > > There is one place in the code where this canonicalization has an ugly > effect: in setup_min_max_conflict_allocno_ids, we have to extend the > min/max value for object 0 of each multi-word allocno, since we may > later record conflicts for them that are due to AhxBh and not apparent > at this point in the code. > > Another possibly slightly ugly case is the handling of > ALLOCNO_EXCESS_PRESSURE_POINTS_NUM; it seemed easiest just to count > these points for each object separately, and then divide by > ALLOCNO_NUM_OBJECTS later on. > > The test for conflicts in assign_hard_reg is quite complicated due to > the possibility Jeff mentioned: the value of hard_regno_nregs may differ > for some element regs of a cover class. I believe this is handled > correctly, but it really is quite tricky. > > Even after more than a week of digging through IRA, I can't claim to > understand all of it. I've made sure that all the places I touched > looked sane afterwards, but - for example - I don't really know yet what > ira_emit is trying to do. There may be bad interactions. > > Still, successfully bootstrapped and regression tested on i686-linux. > Last week I've used earlier versions with an ARM compiler and seemed to > get small code size improvements on Crafty; it also fixes the remaining > issue with PR42502. I'm also thinking of extending it further to do a > DCE of subreg stores which should help PR42575. > > > Bernd > Overall this was relatively straightforward. You touched on most of the non-obvious stuff above. Answers to most of my questions became clear as wrote out the questions. Here's all that's left: In assign_hard_reg, you moved this hunk: + if (allocno_coalesced_p) + { + if (bitmap_bit_p (processed_coalesced_allocno_bitmap, + ALLOCNO_NUM (conflict_allocno))) + continue; + bitmap_set_bit (processed_coalesced_allocno_bitmap, + ALLOCNO_NUM (conflict_allocno)); + } Into the ! ALLOCNO_MAY_BE_SPILLED_P if-clause rather than leaving it to execute unconditionally for each conflict allocno. I don't see the reasoning behind this change. I'm happy to let you and Vlad work out the exact timing for when the bits get committed. Jeff