AIX regression due to DFA scheduler merge
Vladimir Makarov
vmakarov@redhat.com
Fri May 31 14:35:00 GMT 2002
law@redhat.com wrote:
>
> In message <3CF7DA0F.B8C69795@redhat.com>, Vladimir Makarov writes:
> > > If I understand Jeff's earlier comment correctly, the local-alloc
> > > problem may help with the latent bugs uncovered in the proposed
> > > SCHED_GROUP fix. The SCHED_GROUP patch is necessary for other reasons, so
> > > we may need *both* fixes.
> >
> > I've just read email thread about the SCHED_GROUP patch. The idea is
> > clear and its implementation should prevent the bug occurring. So I
> > don't think that the local-alloc problem may help with the latent bugs
> > uncovered in the proposed SCHED_GROUP fix".
> Then we disagree :-) I think it's possible, though unlikely.
>
> > Also I don't think SCHED_GROUP patch is good for all processors and
> > tests. It remove probability to generate a better insn schedules.
> > Although there are cases (when the register pressure is too high) when
> > better insn schedules result in worse code. This is standard conflict
> > of separate insn scheduler and register allocator. It can be solved by
> > some their integration not rejecting opportunities in one optimization.
> > So I don't like the SCHED_GROUP patch (its libcall part).
> >
> > Although the idea not to move clobber too far is right, but it should
> > be solved not by making all LIBCALL as SCHED_GROUP. At least it is
> > better to make only clobber and the 1st insn used the register as a
> > SCHED_GROUP.
> I disagree.
>
> We've had numerous problems in the past because of foreign insns inside
> libcall blocks. In fact, the whole concept behind a libcall block is a
> set of insns which are operated on as a single unit. Scheduling them
> as a block fits into that model a hell of a lot better than letting them
> move about willy-nilly.
>
They are scheduled as a unit in some way. The first an the last insns
of LIBCALL insns will be LIBCALL and RETVAL. But they could moved
inside the LIBCALL and mixed with other LIBCALLS. Scheduling their as a
group remove the two opportunities.
> Also remember that they're scheduled as a block only in the pre-allocation
> scheduling pass. Post allocation the libcall markers are gone and they
> can move about freely.
I'd agree if we have 2nd insn scheduler with integrated register
renaming. But I still believe we lose opportunity to get a better code
scheduling all LIBCALL as the group. There is less freedom of moving on
the 2nd insn scheduling. I think that David's patch gave" a few
improvements" mainly because CLOBBER is not counted as a real insns (so
the scheduler better simulates the processor state).
Vlad
More information about the Gcc-patches
mailing list