Re: AIX regression due to DFA scheduler merge

[law at redhat dot com]

 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.

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.

jeff