This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Merge improvements from new-regalloc-branch: df.[ch] [1/2]
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 17 Mar 2003 12:03:47 -0800
- Subject: Re: [PATCH]: Merge improvements from new-regalloc-branch: df.[ch] [1/2]
- References: <Pine.LNX.4.53.0303171324460.10767@dberlin.org>
Daniel Berlin <dberlin at dberlin dot org> writes:
> This one needs approval from someone other than Matz, and thus, i'm
> submitting it seperately, even though it's unused without the next patch.
>
> 2003-03-17 Daniel Berlin <dberlin at dberlin dot org>
> Merge changes from new-regalloc-branch
>
> From Michael Matz <matz at suse dot de>
> * df.c (read_modify_subreg_p): Always return false.
> (df_ref_record_1): Handle CLASS_CANNOT_CHANGE_MODE smarter.
> (df_uses_record): Ditto.
> * df.h (DF_REF_MEM_OK): New enum member, used to mark ref's which
> it's already okay to use memory operands in (IE doesn't require
> adding another insn or anything).
>
> Index: df.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/df.c,v
> retrieving revision 1.48
> diff -u -3 -p -r1.48 df.c
> --- df.c 11 Mar 2003 09:17:37 -0000 1.48
> +++ df.c 17 Mar 2003 18:23:46 -0000
> @@ -889,6 +892,12 @@ read_modify_subreg_p (x)
> rtx x;
> {
> unsigned int isize, osize;
> + /* Hmm, with exact subreg tracking _no_ writes to subregs are
> + read-mod-write in any way. Inside a STRICT_LOW_PART they are,
> + but not otherwise. Narrow subregs at least clobber the whole word
> + they belong to, wider subregs a whole number of words.
> + Paradoxical subreg writes don't leave a trace of the old content. */
> + return false;
> if (GET_CODE (x) != SUBREG)
> return false;
> isize = GET_MODE_SIZE (GET_MODE (SUBREG_REG (x)));
I believe Michael already commented on this.
> @@ -906,7 +915,10 @@ df_def_record_1 (df, x, bb, insn)
> basic_block bb;
> rtx insn;
> {
> - rtx *loc = &SET_DEST (x);
> + /* We may recursivly call ourselves on EXPR_LIST when dealing with PARALLEL
> + construct. */
> + rtx *loc = GET_CODE (x) == EXPR_LIST ? &XEXP (x, 0) : &SET_DEST (x);
> rtx dst = *loc;
> enum df_ref_flags flags = 0;
>
Can you instead move the initialisation of LOC down below where we're
sure it's safe?
I notice that df_defs_record does:
if (code == SET || code == CLOBBER)
df_def_record_1 (df, XVECEXP (x, 0, i), bb, insn);
the condition might also be a good idea to put in the recursive call
in df_def_record_1.
> @@ -922,7 +934,9 @@ df_def_record_1 (df, x, bb, insn)
...
The remaining changes all look OK.
--
- Geoffrey Keating <geoffk at geoffk dot org>