Re: AIX regression due to DFA scheduler merge

[law at redhat dot com]

In message <200206032003.QAA26010@makai.watson.ibm.com>, David Edelsohn writes:
 > 	If you and Jeff don't like the libcall SCHED_GROUP approach, we
 > can try a patch creating a SCHED_GROUP of a CLOBBER and the following
 > instruction if the following instruction is a SET of the same DEST as the
 > CLOBBER.
 > 
 > 	That would handle the issue-rate scheduling problem without hiding
 > the backward dependency information and allowing full scheduling
 > flexibility.  It would not fix the latent bug of intermixing LIBCALLs,
 > which would need a patch for local-alloc.
 > 
 > 	I do not have any special attachment to the libcall approach.  The
 > main argument for it is that it makes the scheduler obey the meaning of
 > LIBCALL.
Well, I kind-of like the SCHED_GROUP_P call group approach; mostly because
it treats libcalls as a block, which is the way they're supposed to be
treated.  As a secondary benefit it would fix the problem of foreign insns
appearing in a libcall block due to scheduling.

Creating a group of just the clobber & following set may be easier than
creating a whole block, but it's going to leave us with the foreign insn
in libcall block problems.

My personal opinion is we find a way to make the libcall scheduling block
code work.  That should be the job of David Edelsohn, Michael Matz and
myself since we've worked on that code the most.  I think this approach
best fits the current model of how libcall blocks ought to work.  We would
use the clobber+following set model only if we can't make the libcall as
a whole model work.
  
At the same time I'd like to see Vlad make local-alloc be more tolerant
of foreign insns in libcall blocks.  Even if it's not needed to due to the
libcall scheduling work, it would be best of local-alloc was less susceptible
to earlier passes mucking up libcall blocks.

Thoughts?

jeff