This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Initialize INSN_COND


On 06/07/2011 07:39 PM, Alexander Monakov wrote:
> 
> 
> On Fri, 3 Jun 2011, Bernd Schmidt wrote:
> 
>>>> Ok. Although I wonder how sel-sched can end up reusing an entry in
>>>> h_d_i_d?
> 
> Unlike Haifa scheduler, we recompute INSN_LUIDs for each region.  However, we
> call sched_deps_{init,finish} once per function (like Haifa) and that makes us
> reuse entries in h_d_i_d.
> 
> The proposed patch clears h_d_i_d when finishing a region in sel-sched.
> Bootstrapped and regtested on ia64-linux, OK for trunk?

You probably know best, so I'll approve it. Thanks for working on this.

> Normal forward scan is only done to compute insn priorities; now, it will also
> reset INSN_CONDs for instructions followed by an assignment to their
> predicate (for exposed-pipeline targets). After that, sel-sched's dependency
> analysis will treat such instructions as if they had no predicate, which is
> very conservative.  Unfortunately, correctness still may be broken after a
> predicate assignment is moved into a different BB (or copied to one as a
> bookkeeping copy).  I'll try to think of a way to fix it when preparing the
> predication patch.

It's probably not urgent. We can't really use sel-sched on c6x, as I'd
have to add the backtracking machinery to sel-sched for scheduling delay
slots, and I don't understand it well enough to do so.


Bernd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]