From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16758 invoked by alias); 14 Aug 2014 02:56:17 -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 16585 invoked by uid 89); 14 Aug 2014 02:55:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 14 Aug 2014 02:55:32 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7E2tUhW004291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 13 Aug 2014 22:55:30 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-24.phx2.redhat.com [10.3.113.24]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7E2tTDL003364; Wed, 13 Aug 2014 22:55:30 -0400 Message-ID: <53EC2521.3050100@redhat.com> Date: Thu, 14 Aug 2014 02:56:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: David Malcolm CC: gcc-patches@gcc.gnu.org Subject: Re: [PATCH 012/236] Convert DF_REF_INSN to a function for now References: <1407345815-14551-1-git-send-email-dmalcolm@redhat.com> <1407345815-14551-13-git-send-email-dmalcolm@redhat.com> <53EA8535.7090906@redhat.com> <1407961737.28418.153.camel@surprise> <53EBCBCE.3050502@redhat.com> <1407975105.28418.176.camel@surprise> In-Reply-To: <1407975105.28418.176.camel@surprise> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-08/txt/msg01420.txt.bz2 On 08/13/14 18:11, David Malcolm wrote: > On Wed, 2014-08-13 at 14:34 -0600, Jeff Law wrote: >> On 08/13/14 14:28, David Malcolm wrote: >>> Thanks. Although this function gets converted back to a macro in patch >>> 191, I just realized that in the meantime that it's not inlined, as is >>> the case for some of the other macro->function conversions in patches >>> 13-16. >>> >>> Do I need to convert them to inline functions with the appropriate >>> headers, and is that regarded as a sufficiently trivial fix to the stuff >>> you've already reviewed to not need re-review? (I will bootstrap&test). >> I'd just make it a follow-up. #237 ;-) > > Right, but these would be modifications to stuff that only exists > between phases 1-3 of the kit, before going away in phase 4, so although > it might be #237, it would need to be applied when the individual > changes go in. If they're around just through phases #1-#3, then I wouldn't worry about it. > Transient, yes, but given the amount of time for me to simply bootstrap > each candidate patch, the non-inlined functions could last in trunk for > a couple of weeks (there are only 168 hours in a week, and a bootstrap > +regrtest takes about 3 hours on my box, so for 236 patches we're > talking ~4 weeks of compute time just for that). Well, I'd suggest a few things. 1. For the config/ changes, a full bootstrap is not necessary. For those targets which are embedded, just build a stage1 cross to the target to verify it builds and call it good. 2. For targets where you can bootstrap, go ahead and do so, but just on those targets. Some of these you can probably have going in parallel. 3. Some of the changes are so trivial that I'd squash them together in a single build/test cycle. I would even consider seeing all the scaffolding go in as a single chunk. It's nice to see the individuals during the review process, but I wouldn't lose any sleep if bundled those together. > > I guess the underlying point here is that this is a big change and I'm > trying to be fastidious here. Murphy's Law suggests I'm going to break > at least *something* :( Understood, but we don't want to be so fastidious that the time this stuff is in flux is so long that it creates more problems than it would if we took some sensible and safe shortcuts. Jeff