From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27012 invoked by alias); 10 Jan 2014 08:47:20 -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 27001 invoked by uid 89); 10 Jan 2014 08:47:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f43.google.com Received: from mail-wg0-f43.google.com (HELO mail-wg0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 10 Jan 2014 08:47:19 +0000 Received: by mail-wg0-f43.google.com with SMTP id k14so3707121wgh.34 for ; Fri, 10 Jan 2014 00:47:16 -0800 (PST) X-Received: by 10.180.75.115 with SMTP id b19mr1443673wiw.19.1389343635254; Fri, 10 Jan 2014 00:47:15 -0800 (PST) Received: from localhost ([2.28.234.162]) by mx.google.com with ESMTPSA id jw4sm3514841wjc.20.2014.01.10.00.47.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jan 2014 00:47:14 -0800 (PST) From: Richard Sandiford To: Tom de Vries Mail-Followup-To: Tom de Vries ,Vladimir Makarov , gcc-patches , rdsandiford@googlemail.com Cc: Vladimir Makarov , gcc-patches Subject: Re: [PING^2][PATCH] -fuse-caller-save - Implement TARGET_FN_OTHER_HARD_REG_USAGE hook for MIPS In-Reply-To: <52CF3419.6070403@mentor.com> (Tom de Vries's message of "Fri, 10 Jan 2014 00:43:21 +0100") References: <20130330171115.720D3421213@build1-lucid-cs> <52A33995.4090002@mentor.com> <52BAD776.8060805@mentor.com> <52CEA96C.4030108@mentor.com> <8761ptrx28.fsf@talisman.default> <52CF3419.6070403@mentor.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Date: Fri, 10 Jan 2014 08:47:00 -0000 Message-ID: <87bnzkql4e.fsf@talisman.default> MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-01/txt/msg00586.txt.bz2 Tom de Vries writes: >> Why not just collect the usage information at >> the end of final rather than at the beginning, so that all splits during >> final have been done? > > If we have a call to a leaf function, the final rtl representation does not > contain calls. The problem does not lie in the final pass where the callee is > analyzed, but in the caller, where information is used, and where the unsplit > call is missing the clobber of r6. Ah, so when you're using this hook in final, you're actually adding in the set of registers that will be clobbered by a future caller's CALL_INSN, as well as the registers that are clobbered by the callee itself? That seems a bit error-prone, since we don't know at this stage what the future caller will look like. (Things like the target attribute make this harder to predict.) I think it would be cleaner to just calculate the callee-clobbered registers during final and leave the caller to say what it clobbers. FWIW, I still think it'd be better to collect the set at the end of final (after any final splits) rather than at the beginning. >> For other cases (where the usage isn't explicit >> at the rtl level), why not record the usage in CALL_INSN_FUNCTION_USAGE >> instead? >> > > Right, we could add the r6 clobber that way. But to keep things simple, I've > used the hook instead. Why's it simpler though? That's the kind of thing CALL_INSN_FUNCTION_USAGE is there for. Thanks, Richard