From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11790 invoked by alias); 20 Feb 2004 05:44:44 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 11781 invoked from network); 20 Feb 2004 05:44:43 -0000 Received: from unknown (HELO mta6.wss.scd.yahoo.com) (66.218.85.37) by sources.redhat.com with SMTP; 20 Feb 2004 05:44:43 -0000 Received: from specifixinc.com (24.7.123.142) by mta6.wss.scd.yahoo.com (7.0.016) (authenticated as jim@tuliptree.org) id 40290248005E3197; Thu, 19 Feb 2004 21:44:26 -0800 Message-ID: <40359EC1.9090402@specifixinc.com> Date: Sat, 21 Feb 2004 13:45:00 -0000 From: Jim Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 MIME-Version: 1.0 To: Kazu Hirata CC: gcc-patches@gcc.gnu.org Subject: Re: Unreviewed patches References: <20040214.140031.71087211.kazu@cs.umass.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-02/txt/msg01884.txt.bz2 Message-ID: <20040221134500.trFmgiT4MYjKdKfAir-5PEun5qNNY59BG0FNvdbx3hk@z> Kazu Hirata wrote: > [patch] function.c: Move USE as far down as possible. > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00144.html There can be more than one USE. Note that diddle_function_return handles PARALLEL, in which case multiple USEs are emitted. For instance, build a mipsisa64-elf target, and compile a function that returns complex float. Maybe we should verify that this is a return reg? In the simple case, you can check REG_FUNCTION_VALUE_P, but that doesn't work when the return value is a PARALLEL. We could use FUNCTION_VALUE_REGNO_P. This check is probably not important. You check for a register in the USE. I wonder if anything else can appear here, like a SUBREG, or a STRICT_LOW_PART. It seems unlikely, but if it does happen, then a USE insn does not get moved. This is probably not important. When scanning insns, you only special case JUMP_INSNS. You should probably also special case other things like CODE_LABEL, CALL_INSN. We shouldn't make assumptions about what might appear here. Maybe just modify the code to check for GET_CODE (insn) != INSN instead of GET_CODE (insn) == JUMP_INSN? Instead of using delete_insn/emit_insn_before, you should use reorder_insns. See the other examples in the same function that move instructions around. Long term, I think it is better to try to eliminate these end-of-function USE markers than to try to add more special purpose code for them. Another issue, why does a USE inhibit peephole2 optimization anyways? There seems to be no reason for it to do so. You could try modifying the peephole2 optimizer to ignore USE insns. > [patch] Allow translation of the copyright symbol. (take 3) > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg01277.html OK. > [patch] Enable 20040130-1.c and 961203-1.c only when __INT_MAX__>= 2147483647L. > http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00881.html OK. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com