From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14032 invoked by alias); 10 Aug 2007 22:42:11 -0000 Received: (qmail 13895 invoked by uid 22791); 10 Aug 2007 22:42:10 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Aug 2007 22:42:03 +0000 Received: (qmail 27992 invoked from network); 10 Aug 2007 22:42:02 -0000 Received: from unknown (HELO bullfrog.localdomain) (sandra@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Aug 2007 22:42:02 -0000 Message-ID: <46BCE979.5030801@codesourcery.com> Date: Fri, 10 Aug 2007 22:42:00 -0000 From: Sandra Loosemore User-Agent: Thunderbird 2.0.0.5 (X11/20070716) MIME-Version: 1.0 To: GCC Patches CC: Richard Sandiford , David Ung , Nigel Stephens , Mark Mitchell Subject: status of back end reinitialization patch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-08/txt/msg00717.txt.bz2 When I was retesting the back end reinitialization and mips16 function attribute patches after implementing changes from the last round of review (thanks Richard!), I ran into something that looks like a show-stopper problem, and I need to get some feedback about how to proceed. The problem is that the existing patch hooks into tree_rest_of_compilation as the point at which to invoke the back end reinit function. But this turns out to be too late. The specific problem I ran into was an example where stuff in tree-vect-generic.c was deciding not to lower a V2HImode multiplication based on seeing backend support for it in the optab -- but then we reset the optab before doing the RTL generation, which became unhappy with being handed an operator it didn't know how to expand. Since there are likely other middle-end transformations that rely on testing back end features, at the very least we need to put a hook in tree_lowering_passes as well. More generally, it probably ought to be done whenever we set cfun. We've been having some internal discussion about moving it into push/pop_cfun and auditing all other instances where cfun is currently being set directly to see if they can be rewritten to use stack discipline. Or perhaps we can introduce some new primitives here. Because this means that the back end mode-switching hook might be called many times per function, it starts to become more critical that it do some caching. The hook function we've implemented for the MIPS16 stuff checks to see whether we're already in the right mode, so at least the reinitialization cost will only happen when there really is a mode change, and be close to zero otherwise. As I said the first time around with this patch, the "right" solution is really to wrap up the back end state into first-class objects that can just be swapped in and out, but that may not be practical at this point. Anyway.... where does all this leave the current patch? I've tidied up the current version; except for the problem noted above, it's testing quite cleanly on MIPS with -mflip-mips16. I've decided to break it up into smaller pieces so that we can consider them individually. One of the MIPS-specific cleanups (the part to kill the mips16_hard_float variable) has already been split out and committed separately. I've split the non-MIPS-specific part into two pieces now; one to do the separation of the initialization actions into target-specific and non-target-specific pieces, and one to add the target hooks. I know there's general resistance to committing half-implemented features, but if we're going to go ahead with this idea of supporting back end mode changes, then some variant of the initialization reorganization is going to have to be included anyway, so perhaps this could be considered on its own merits while we're still hashing out the details of where the right place for the hook is. I'll repost the three remaining pieces (those two plus the remaining MIPS-specific part) here shortly. Comments, thoughts, flames, etc? I wasn't too sure about posting this on a Friday evening, but maybe anybody who's still reading their mail can think about it over the weekend. ;-) -Sandra