This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: AIX regression due to DFA scheduler merge
- From: law at redhat dot com
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Vladimir Makarov <vmakarov at redhat dot com>, gcc-patches at gcc dot gnu dot org, Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 03 Jun 2002 17:10:59 -0600
- Subject: Re: AIX regression due to DFA scheduler merge
- Reply-to: law at redhat dot com
In message <200206032241.SAA22200@makai.watson.ibm.com>, David Edelsohn
writes:
I was working on resurrecting my old sched_analyze_1 patch, so I
> will be interested to see what you implemented. BTW, moving the libcall
> test to the beginning of sched_analyze at least bootstraps better than the
> previously tested version of the patch.
>
> While working on my version of the patch, I was pondering whether
> we should handle bare CLOBBERs while we're fixing this. In other words.
>
> if (!reload_completed && GET_CODE (PATTERN (insn)) == CLOBBER)
> {
> if (LIBCALL)
> create_sched_group_for_libcall;
> else
> if (set = single_set (NEXT_INSN (insn)) != 0
> && SET_DEST (set) == XEXP (PATTERN (insn), 0))
> create_sched_group_for_set;
> }
I doubt it's worth doing this for naked clobbers -- my first question would be
under what conditions do those naked clobbers exist and is there any value
in them continuing to exist after the first pass of life analysis.
In the past naked clobbers were solely to prevent spurious uninitialized
variable warnings. Once we've finished life analysis (where those warnings
are issued), naked clobbers should really just go away as they convey no
useful information.
jeff