This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Gcc 3.1 performance regressions with respect to 2.95.3
- From: law at redhat dot com
- To: David Edelsohn <dje at watson dot ibm dot com>
- Cc: Michael Matz <matzmich at cs dot tu-berlin dot de>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 May 2002 08:01:01 -0600
- Subject: Re: Gcc 3.1 performance regressions with respect to 2.95.3
- Reply-to: law at redhat dot com
In message <200205290253.WAA30328@makai.watson.ibm.com>, David Edelsohn
writes:
> If it works to not clear SCHED_GROUP_P at the beginning of the
> group, that's great. I was concerned whether those objects were allocated
> with the field zero so that it might randomly be set prior to the first
> sched_analyze pass.
The only other way for the bit in question to get set for an INSN, CALL_INSN
or JUMP_INSN would be during SSA-DCE where we use it to mark dead code
(which is later deleted).
If we were really worried about this, then we'd just have a pass over all
the insns at the start of scheduling to clear SCHED_GROUP_P rather than
clearing
it in move_insn, sched_analyze, etc.
jeff