Scheduling problem - A more detailed explain

[Jim Wilson]

ÎâêØ 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