This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Scheduling problem - A more detailed explain
- From: Jim Wilson <wilson at specifix dot com>
- To: ÎâêØ <wu dot andrew dot xi at gmail dot com>
- Cc: gcc <gcc at gcc dot gnu dot org>, xzfkiller at gmail dot com
- Date: Wed, 10 Oct 2007 14:46:17 -0700
- Subject: Re: Scheduling problem - A more detailed explain
- References: <f63285730710081749y4e90b067x7a56fa9be6394cee@mail.gmail.com>
ÎâêØ wrote:
Well... Is there anything I miss or forget to do ?
Someone needs to step through code in a debugger and try to figure out
what is going wrong.
I made an initial attempt at that. I hacked gcc a little to try to
force a failure with a contrived testcase. The first thing I noticed is
that I pointed you at the wrong bit of code. The rws_access_reg code is
used for placing stop bits, which is not the problem here. The problem
here is in the scheduler. Unfortunately, this leads to a second
problem. How this works in the scheduler depends on what gcc sources
you are using. There is the pre-dataflow merge code and the
post-dataflow merge code. I don't know which one you are using. From
earlier comments, I'm guessing that you are using some snapshot from mid
to early summer. It would be helpful to know exactly what sources you
are starting from. Worst case, I might also need your gcc patches, if I
can't find a way to trigger the failure on my own.
The scheduler dep code is in sched-deps.c. Try looking at
sched_analyze_insn. As before, it does use hard_regno_nregs so in
theory it should be working.
Do we know for sure that the scheduler is failing here? Have you looked
at -da RTL dumps to verify which pass is performing the incorrect
optimization?
Currently, gcc only emits these pr reg group save/restores in the
prologue and epilogue, and we have scheduling barriers after/before the
prologue/epilogue, so it is possible that there is a latent problem here
which has gone unnoticed simply because it is impossible to reproduce
with unmodified FSF gcc sources.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com