Re: Some Haifa scheduler bugs

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970819092828.291B-100000@starsky.informatik.rwth-aa
chen.de>you write:
  > 	* haifa-sched.c (target_bb, bbset_size, dom, prob, rgn_nr_edges,
  > 	rgn_edges, edgeset_size, edge_to_bit, pot_split, ancestor_edges):
  > 	Make static.
I've already got these installed into egcs, plus some others that
you didn't make static.

  > 	(move_insn): Call reemit_notes for every insn in a SCHED_GROUP.
See my last message -- that's the code I'm running right now.  If it
doesn't work, let me know and we can iterate to a solution.

  > 	(schedule_block): When checking whether an insn is the 
  > 	basic_block_head of a different block, use the first insn in the
  > 	same SCHED_GROUP instead of the insn itself.
Done.  Slightly differently, but should be functionally equivalent
and a little clearer to someone who might read the code later.


  > 	(debug_dependencies): GET_RTX_NAME takes an rtx code, not an rtx.
Done.

Jeff

Re: A prototype patch for tree.h/tree.def/calls.c

[H.J. Lu]

> 
> 
> > #define NEED_enum_rtx_code    
> > #include "rtl.def"                
> > #undef NEED_enum_rtx_code                                        
> > #define NEED_enum_machine_mode                                     
> > #include "machmode.def"               
> > #undef NEED_enum_machine_mode                       
> > 
> > .....
> > extern int ix86_expand_binary_operator 
> >         PROTO ((enum rtx_code, enum machine_mode, struct rtx_def *[]));
> > .....
> 
> This looks ugly.  I agree with Kenner's comments a while back about
> changes to the #include conventions in gcc.  Target .h files shouldn't
> need to include any gcc files.  We should minimize nested includes
> within gcc.

It does look ugly. But it works.

> 
> There are a few ways to solve the problem of the target .h file
> needing more definitions.
> 
> We could make the rtl and tree definitions visible in every gcc file
> (like the machine modes are now).  Then tm.h would have all types
> available.
> 
> We could require tm.h to test whether it is being used in a front-end
> or back-end context and not use any names not defined in that context.
> 
> Either of these requires rtl.h (less the very few target-dependent
> macros) or tree.h to be included _before_ tm.h.  The changes are
> simple but almost every file in gcc (including machine descriptions)
> would need to change.  If we plan to do a front/middle/back-end
> interface cleanup it would be best to defer the changes until then and
> make them all at once.

I have spent the time to make a patch. Why should we wait for something
which noone knows when it will be ever done? Besides my patch is small
enough that it is easy to take out.

> 
> Another option is to declare function arguments as integers instead of
> enumerated types in tm.{c,h}.
> 

I don't know if it is a good idea since those *.def are included
multiple time to have a correct match.


-- 
H.J. Lu (hjl@gnu.ai.mit.edu)

Re: A prototype patch for tree.h/tree.def/calls.c

[Jeffrey A Law]

  In message <m0x0r16-0004edC@ocean.lucon.org>you write:
  > > 
  > >   In message <m0x0opG-0004edC@ocean.lucon.org>you write:
  > >   > I have some problem s with my emails for the past few days. I may
  > >   > have lost some. I only remember your comments on BUFSIZ being a macro
  > ,
  > >   > which turned out ok. What else?
  > > Relatively minor stuff.
  > > 
  > > For this pass #if 0 the prototypes for xmalloc and related funtions;
  > > once the bulk of the prototypes are in, please submit a separate
  > > patch to enable prototyping of xmalloc and related functions.
  > 
  > On my machine, they are enabled.
Please disable them for the patch.

  > That is exactly the problem with size_t. How can you be
  > sure size_t is available on all systems when xmalloc ()
  > is used? many xmalloc () in gcc use unsigned. I think
  > it makes some senses.
NO!  You simply can't change from size_t to unsigned, that's
just plain wrong.

Seems to me the right way to do this is with autoconf.


  > I have spent weeks on it. I am afraid I may make some
  > stupid mistakes if I try to reformat it. After all,
  > those prototypes are mainly for compiler. Please feel
  > free to reformat it. Thanks.
Then they're not likely to go in anytime soon.  I don't have the
time to spend reformatting all your changes.

  > Here is what I have in my i386.h:
  > 
  > #define NEED_enum_rtx_code    
  > #include "rtl.def"                
  > #undef NEED_enum_rtx_code                                        
  > #define NEED_enum_machine_mode                                     
  > #include "machmode.def"               
  > #undef NEED_enum_machine_mode                       
I had a feeling you'd done something like this -- let's punt this
for now until we can come up with something better.


So, it seems to me you need to do 3 things:

  * #if0 the xmalloc and friends prototypes.
  * Don't mess with the enum rtx_code and enum tree_code stuff
    right now.
  * Do some minor formatting.

We're not talking about a lot of work that you'd need to do to
get your patches installed immediately.

Jeff

Re: Unique SMTP From header?

[Dan A. Dickey]

This is a multi-part message in MIME format.
--------------34E1C86DEF52D15062591CA0
Content-Type: text/plain; charset=us-ascii
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Peter Seebach wrote:

> >Is it possible to set the envelope sender of all mail coming from the
> list
> >to some unique address, e.g. egcs-errors@cygnus.com, or something
> similar?
> >It would make sorting with procmail much easier.
>
> Seconded!
>
> I hope in the near future to be able to sort my mail, and I am hoping
> for
> all of my mailing lists to be easily identifiable.
>
> -s

Isn't the To: egcs@cygnus.com unique enough?
Of course, it might appear in a CC: line.
    -Dan

--
Dan A. Dickey  http://www.transition.com/
mailto:ddickey@transition.com


--------------34E1C86DEF52D15062591CA0
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Dan Dickey
Content-Disposition: attachment; filename="vcard.vcf"

begin:          vcard
fn:             Dan Dickey
n:              Dickey;Dan
org:            Transition Networks, Inc.
adr:            6475 City West Parkway;;;Eden Prairie;MN;55344;USA
email;internet: ddickey@transition.com
title:          Sr. Software Engineer
tel;work:       612-941-7600
tel;fax:        612-941-2322
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
end:            vcard


--------------34E1C86DEF52D15062591CA0--

Re: Some Haifa scheduler bugs

[Ian Lance Taylor]

   Date: Fri, 5 Sep 1997 13:44:34 +0200 (MET DST)
   From: Bernd Schmidt <crux@Pool.Informatik.RWTH-Aachen.DE>

   >   In message < Pine.SOL.3.90.970903184242.6496A-100000@bond.informatik.rwth-aachen.de >you write:
   >   > How can reload generate incorrect code in this case except if the lifetime
   >   > of a hard register gets extended by the scheduler or some other optimizer?
   > When loading of an argument register requires a reload, which may force
   > reload to clobber a previously loaded argument register.

   Now I'm confused. Isn't the reload_address_base_reg_class stuff supposed to
   handle that case?

Yes, it is.  I wrote it to handle the MIPS16, which has only 8 general
purpose registers but, for reasons of compatibility with standard
MIPS, uses 4 of them for register passing.  (The MIPS16 support will
get into the general release one of these days--it's all sitting on a
badly hacked up branch right now.)

However, people have encountered cases which fail when using the more
baroque MIPS EABI calling convention, which uses 8 registers for
register passing (but not the same 8 that the MIPS16 uses--it's too
complicated to get into now).

My personal attitude is that people should try using the register
parameters option on the ix86, but should not depend upon it to work,
and should be prepared to fix the problems themselves rather than
merely reporting them.

Note that the ix86 is more likely to work correctly than the MIPS16,
because the ix86 can load a value directly from memory, whereas the
MIPS16 must first construct the address in a register (i.e., the ix86
has a 32 bit direct addressing mode, but the MIPS16 does not).

Ian

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message < Pine.SOL.3.90.970905134354.4356D-100000@tracy.informatik.rwth-aachen.de >you write:
  > Now I'm confused. Isn't the reload_address_base_reg_class stuff supposed to
  > handle that case?
I haven't read all the new code, but based on experiences of someone in
Cygnus porting to a register poor machine that passes arguments in registers
my impression was that the reload_address_base_reg_class stuff wasn't
complete or sufficient to prevent incorrect code from being generated.

Jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

>   In message < Pine.SOL.3.90.970903184242.6496A-100000@bond.informatik.rwth-aachen.de >you write:
>   > How can reload generate incorrect code in this case except if the lifetime
>   > of a hard register gets extended by the scheduler or some other optimizer?
> When loading of an argument register requires a reload, which may force
> reload to clobber a previously loaded argument register.

Now I'm confused. Isn't the reload_address_base_reg_class stuff supposed to
handle that case?

Bernd

Re: Some Haifa scheduler bugs

[David Edelsohn]

>>>>> "David S Miller" writes:

Jeff> I'm less familiar with how this works under aix or with
Jeff> ultrasparcs/solaris, but I assume they both do something relatively
Jeff> reasonable.

David> Naturally, this depends upon OS support, and I think Solaris does map
David> page 0 in this special way, or they check the load instruction which
David> was executed by the user once the fault handling call chain determines
David> that the access was in outer space.

	The IBM XL compilers have a switch to disable the speculative load
optimization, but AIX does not have any way to make loads from page 0
generate a fault -- it is a general feature provided by the OS without
user control.  Neither the POWER/PowerPC architecture nor the executable
header have any selectable switch to enable or disable that general
functionality.

David

Re: Some Haifa scheduler bugs

[David S. Miller]

   Date: Thu, 04 Sep 1997 12:12:15 -0600
   From: Jeffrey A Law <law@hurl.cygnus.com>

   I'm less familiar with how this works under aix or with
   ultrasparcs/solaris, but I assume they both do something relatively
   reasonable.

On the UltraSparc normal load/store instructions still trap on bogus
pointers like they always have.

The compiler must emit a special load instruction (with an address
space specifier for the "no-fault" address space) when it wants a
speculative load.  The chip will not fault on a NULL pointer if page 0
of the process has the "allow non-faulting load" attribute set, when
you use these special load instructions.  Non-faulting stores do not
exist.

Naturally, this depends upon OS support, and I think Solaris does map
page 0 in this special way, or they check the load instruction which
was executed by the user once the fault handling call chain determines
that the access was in outer space.

I lack the support currently on sparc64-linux, but it will be added
should a native compiler out there begin to emit the instructions ;-)

Later,
David "Sparc" Miller
davem@caip.rutgers.edu

Re: Some Haifa scheduler bugs

[meissner]

Note if people are going to use -fsched-spec-load-dangerous, I think there are
bugs in the current Haifa code.  I originally enabled it in the AIX port when
I was first testing haifa years ago, and eventually removed setting it, since
it was assuming all loads could be done speculatively, when it should have
only optimized things like:

	p != NULL && *p

(either that or somebody changed the default until AIX so that page 0 was
no longer mapped by default -- it was quite some time ago).

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message < 199709041633.MAA20790@melange.gnu.ai.mit.edu >you write:
  > Good summary.
It's not 100% accurate, but it's close enough for this discussion :-)

  > The way I look at it is, all things being equal, I'd prefer an OS
  > default to faulting on dereferecing NULL when running generic C code
  > simply because C code shouldn't be dereferencing NULL.
Agreed.

HPUX does it backwards -- it defaults to allowing the dereference.
However the GCC port passes the magic flags to the linker to turn on
faulting by default :-)

It's a choice that can be made on a file by file basis -- and with
a little work one can even change the magic bit in the executable
header to change the behavior of a particular file.

I'm less familiar with how this works under aix or with ultrasparcs/solaris,
but I assume they both do something relatively reasonable.

  > not scheduling NULL dereferences.  Generally it is better to
  > default to not doing potentially hurtful optimizations, since users
  > who know they want optimizations know enough to specify them;
That's my general opinion too.

  > Note that the documentation should be *very* clear that, even if
  > this option is enabled, it does *not* guarantee that C (or Fortran
  > etc.) code can then be written that explicitly dereferences NULL.
Absolutely.

Jeff

Re: Some Haifa scheduler bugs

[Craig Burley]

>Actually, we've come full circle over the years on this issue.
>
>First it was good, because "all the (unix) world was a pdp/vax" and you were
>allowed to do this on those systems.
>
>Then later as people decided depending on such behavior was a bad programming
>practice OS folks started forcing null pointer dereferences to cause faults
>and people fixed their code to avoid dereferencing null pointers.
>
>Now we have code which explicitly avoids dereferencing null pointers, but
>some OSs (hpux, aix, solaris?) have options to allow null pointer dereferences
>to allow the scheduler to perform more speculative code motions.

Good summary.

The way I look at it is, all things being equal, I'd prefer an OS
default to faulting on dereferecing NULL when running generic C code
simply because C code shouldn't be dereferencing NULL.  If it is,
maybe it'll be "lucky" and get the right values (behave the way it
happened to on the original developer's system) if the system allowed
it, or maybe it'll be "lucky" and never care, but it's too risky to
*assume* it'll be correct.  I'd rather have it crash and not be correct,
and make a specific decision to risk running it with such faulting
disabled, personally.

However, that view is basically orthagonal to whether an OS should
default to faulting for *generated* code that could run faster if
such faulting was disabled.  In this case, of course, good engineering
would mandate that the executable be marked with a flag saying "this
executable contains code that assumes dereferencing, but never using,
NULL is fast"; which in turn would suggest that objects be marked
that way and the linker cooperate accordingly; which the compiler
would in turn set when the appropriate optimizations were enabled or,
better yet, actually used; but, failing that, the usual black-box
approach we take to such thing should suffice.

Essentially this seems to me a lot like the issue of NaNs in code
using floating-point arithmetic on IEEE 754 machines.  Some people
want any generation of a NaN to immediately cause a fault, because
they want the potentially buggy code they're running to cause an
exception rather than silently produce wrong results.  OTOH, others
want NaN generation to silently and speedily continue, because
that's what makes sense for lots of code written (or compiled) to
the IEEE 754 model.

Unfortunately, we do seem to collectively refuse to provide, or use,
any kinds of clear markers in our code and utilities that explicitly
*mean* "This code should never generate NaNs" or "This code certainly
can generate NaNs and still be working well", so picking the right
defaults becomes a religious issue.

Someday I hope the free-software community will offer solutions to
this overall problem.  (Other things like tracking the licensing
requirements of compiled code through objects to executables and
libraries are part of it.)

In the meantime, I'd suggest using the approach of not defaulting
to *either* behavior, that is, leaving the default to be whatever
the target configuration wants, and maybe *that* could default to
not scheduling NULL dereferences.  Generally it is better to
default to not doing potentially hurtful optimizations, since users
who know they want optimizations know enough to specify them; but
it seems reasonable for a given target to specify that this kind
of optimization is actually not hurtful.

However, this might violate some other worthwhile principles in
general, or for egcs/gcc in particular.  For example, the documentation
would have to specify that the default depends on the target
system's configuration.

Note that the documentation should be *very* clear that, even if
this option is enabled, it does *not* guarantee that C (or Fortran
etc.) code can then be written that explicitly dereferences NULL.

That is, the issue of whether NULL-dereferencing is safe for
code *generation* should be kept very distinct from whether
NULL-dereferencing is needed by the code being compiled.  If
the latter seems like a useful thing to provide, that should
be a separate option (at the very least; in fact, it should be
a source-level language construct, per my comments above, but
that's probably beyond the scope of egcs at this point).

(Right now it might seem nonsensical for the user to specify
one option, or getting it as a default for a target, saying
"don't schedule NULL dereferences" and another saying "this
code assumes it can safely dereference NULL".  But these are
two different concepts, and, in the future, combining them might
actually produce a useful result, e.g. the compiler could
generate code to check all uncertain addresses before
dereferencing them.  In the meantime, a warning could be issued
if the combination isn't supported, something like what we do
for `-Wuninitialized -O0'.)

        tq vm, (burley)

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message < 9709031838.AA27038@kona. >you write:
  > If that switch indeed depends on not faulting references to zero, it
  > probably isn't worth having.
Maybe, maybe not.  That's one of the things I think needs to be evaluated
for haifa.

  > Or if it's kept it needs a warning that in many OS's it will fail.
Yes.  Or more along the lines of "this option should only be used on systems
which allow a dereference of a null pointer" -- explain when it will fail
instead of saying "it'll fail on many OS's".

  > The reason is that faulting on references
  > to zero is universally considered a Good Thing and many OS's go out of
  > their way to provide that feature.
Actually, we've come full circle over the years on this issue.

First it was good, because "all the (unix) world was a pdp/vax" and you were
allowed to do this on those systems.

Then later as people decided depending on such behavior was a bad programming
practice OS folks started forcing null pointer dereferences to cause faults
and people fixed their code to avoid dereferencing null pointers.

Now we have code which explicitly avoids dereferencing null pointers, but
some OSs (hpux, aix, solaris?) have options to allow null pointer dereferences
to allow the scheduler to perform more speculative code motions.

I'm undecided either way; if there's a significant win on these systems, then
I'm tempted to leave the option.  If there's no significant benefit, then I'm
tempted to remove the option (both to simplify the compiler/scheduler and to
avoid people unknowingly using the option, then sending bugs 'cuz their
system didn't support null pointer dereferences).

Jeff

Re: Some Haifa scheduler bugs

[Richard Henderson]

> If that switch indeed depends on not faulting references to zero, it
> probably isn't worth having.

There exist CPUs, e.g. UltraSparc, that have special non-faulting loads
that are explicitly architected to support this kind of optimization.


r~

Re: Some Haifa scheduler bugs

[Jim Wilson]

	Basically any machine that defines SMALL_REGISTER_CLASSES and passes args in
	registers is playing with fire -- reload can and will silently generate incorrect
	code for such targets.  For that reason I _highly_ recommend against using
	registers for parameter passing on the x86 targets.

I'll second it.  The x86 regparm attribute is unsafe, and should not be used.
It might be possible to fix the problem by hacking reload and the x86 port,
but it doesn't seem very worthwhile.  The problem is hard to fix, and exposes
people to unnecessary risks of compiler bugs.  There are probably easier
ways to get faster x86 code.

Jeff didn't mention it, but it is also unwise to schedule before
register allocation if SMALL_REGISTER_CLASSES is defined, even if you
are not using register parameters.  The goal of the scheduler is to reduce
pipeline stalls at the expense of increasing register pressure.  This is
exactly the wrong thing to do on a SMALL_REGISTER_CLASSES machine such as
the x86, because you will get so many extra spills that the code may run
slower.  A scheduler that has different goals might be able to do better,
but given the way the existing scheduler works, I would recommend avoiding
it before register allocation on the x86.

Jim

Re: Some Haifa scheduler bugs

[David Edelsohn]

>>>>> Paul Koning writes:

Paul> "law@cygnus.com" wrote:
>> However, for execution tests that fail, I wonder how many (if any) are 
>> caused by -fsched-spec-load-dangerous.  If I remember right that
>> relies on the OS to support non-faulting loads from zero.

Paul> If that switch indeed depends on not faulting references to zero, it
Paul> probably isn't worth having.  Or if it's kept it needs a warning that
Paul> in many OS's it will fail.  The reason is that faulting on references
Paul> to zero is universally considered a Good Thing and many OS's go out of
Paul> their way to provide that feature.

	I disagree with your justification that faulting on dereferncing
address zero is considered a Good Thing.  This depends on your priorities
and the correctness of your program.  I do not want to get into a general
discussion about programming styles and kernel design, but speculatively
dereferencing zero is very important for good performance on some systems;
some operating systems go out of their way specifically to make page zero
valid, as opposed to making it a VM error.  This needs to be set in the
configuation file on a system-by-system basis and not universally enabled
or disabled.

David

Re: Some Haifa scheduler bugs

[Paul Koning]

"law@cygnus.com" wrote:
> However, for execution tests that fail, I wonder how many (if any) are 
> caused by -fsched-spec-load-dangerous.  If I remember right that
> relies on the OS to support non-faulting loads from zero.

If that switch indeed depends on not faulting references to zero, it
probably isn't worth having.  Or if it's kept it needs a warning that
in many OS's it will fail.  The reason is that faulting on references
to zero is universally considered a Good Thing and many OS's go out of
their way to provide that feature.

	paul

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message < Pine.SOL.3.90.970903184242.6496A-100000@bond.informatik.rwth-aachen.de >you write:
  > How can reload generate incorrect code in this case except if the lifetime
  > of a hard register gets extended by the scheduler or some other optimizer?
When loading of an argument register requires a reload, which may force
reload to clobber a previously loaded argument register.


jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> In general, that's not going to work.
> 
> Basically any machine that defines SMALL_REGISTER_CLASSES and passes args in
> registers is playing with fire -- reload can and will silently generate incorrect
> code for such targets.  For that reason I _highly_ recommend against using
> registers for parameter passing on the x86 targets.

How can reload generate incorrect code in this case except if the lifetime
of a hard register gets extended by the scheduler or some other optimizer?

Bernd

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message < Pine.SOL.3.90.970903182436.5858D-100000@bond.informatik.rwth-aachen.de >you write:
  > Ok, I'll retry the tests without that option. But this is not the only
  > case that Haifa can create incorrect code; there is an additional problem
  > that can show up on any SMALL_REGISTER_CLASSES machine. Haifa can increase
  > the lifetime of pseudo registers, which can cause incorrect code to be
  > generated. These examples were made on an i586-linux configuration with
  > egcs-970828:
[ ... ]
In general, that's not going to work.

Basically any machine that defines SMALL_REGISTER_CLASSES and passes args in
registers is playing with fire -- reload can and will silently generate incorrect
code for such targets.  For that reason I _highly_ recommend against using
registers for parameter passing on the x86 targets.

Turning on the instruction scheduler in that case is just going to make a
bad problem worse -- but the problem isn't the instruction scheduler itself.

  > It seems that at least these changes are necessary:
  > 1. Function arguments must be moved into pseudos immediately at the top
  > of a function.
Nontrivial to do in haifa.

jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> 
> I suspect all the cases where the compiler itself is core dumping
> is the SCHED_GROUP_P problem in move_insn.

Likely.
 
> However, for execution tests that fail, I wonder how many (if any) are 
> caused by -fsched-spec-load-dangerous.  If I remember right that
> relies on the OS to support non-faulting loads from zero.

Ok, I'll retry the tests without that option. But this is not the only
case that Haifa can create incorrect code; there is an additional problem
that can show up on any SMALL_REGISTER_CLASSES machine. Haifa can increase
the lifetime of pseudo registers, which can cause incorrect code to be
generated. These examples were made on an i586-linux configuration with
egcs-970828:

darkstar:/usr/src # cat tsth1.c
int d,e;

int foo(int, int, int) __attribute__ ((regparm (3)));

int foo(int a, int b, int c)
{
  d /= e;
  return a + b + c;
}

int main()
{
  int a;
  d = 400; e = 4;
  a = foo(3,2,1);
  if (a != 6)
    abort ();
  return 0;
}
darkstar:/usr/src # gcc -B/usr/src/egcs-970825/gcc/stage2/ -fschedule-insns -fsched-reverse-S -O tsth1.c
darkstar:/usr/src # a.out
Aborted
darkstar:/usr/src # cat tsth2.c
volatile int d,e;

int foo(int, int, int) __attribute__ ((regparm (3)));

int foo(int a, int b, int c)
{
  return a + b + c;
}

int main()
{
  int a;
  d = 400; e = 4;
  a = foo(3,2,1);
  d /= e;
  if (a != 6)
    abort ();
  return 0;
}
darkstar:/usr/src # gcc -B/usr/src/egcs-970825/gcc/stage2/ -fschedule-insns -fsched-reverse-S -O tsth2.c
darkstar:/usr/src # a.out
Aborted

It seems that at least these changes are necessary:
1. Function arguments must be moved into pseudos immediately at the top
of a function.
2. For function calls, all insns from the first one setting an argument
register to the one copying the return value out of a hard reg must be
one big SCHED_GROUP.
3. Insns setting the return value reg must not be moved.
I don't know whether it's possible for a hard reg to be explicitly mentioned
in any other way; I think it is not possible.

> Also note that the -fsched-reverse-{R,S} are for testing purposes
> only, they actually pessimize code in an attempt to test the
> scheduler more fully.  Long term I expect to rip them out of the
> scheduler.

Why, I think it's useful to have this kind of self-check code - it helps
to check for bugs in the scheduler.

Bernd

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  > I think you won't get the right return value. You want to return the
  > last insn in a SCHED_GROUP or a note that was placed after it.
  > I had my reasons to use two loops ;)
You're right.  Seems to me that the return value for move_insn should
always be the return value from the first call to reemit_notes.  Correct?

In which case it's pretty simple to record the return value from
the first call to reemit_notes.

And I don't doubt you had good reasons to use two loops; I just want
to make absolutely sure I understand the problem.  Handling of notes
and SCHED_GROUP_P insns have both been particularly difficult areas
of the scheduler to implement correctly.

  > The whole affair with SCHED_GROUP_P is extremely messy.
Agreed.

  > How about using extra data structures that describe which insns
  > to schedule together, which notes to put before them, and the
  > dependencies between them.
I'm all for it.

  > scheduled together with an insn might make the code clearer. I think it
  > would fit in better with the fact that Haifa schedules forward. I didn't
  > try it, though; maybe there are problems with that approach, too.
Well, haifa does both forward and backward analysis -- so it might
just move the problematical code elsewhere in the scheduler.

jeff

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970826140826.2901J-100000@maigret.informatik.rwth-aa
chen.de>you write:
  > > 
  > >   > I'll re-run c-torture with the unmodified scheduler and
  > >   > report all failures.
  > > Please do.  It'll make tracking these things down easier.
  > 
  > Sorry about the delay, our mailserver didn't quite work yesterday.
  > Here are the failures I get without the reemit_notes fix on an
  > i586-linux configuration:
No problem.

I suspect all the cases where the compiler itself is core dumping
is the SCHED_GROUP_P problem in move_insn.
 
However, for execution tests that fail, I wonder how many (if any) are 
caused by -fsched-spec-load-dangerous.  If I remember right that
relies on the OS to support non-faulting loads from zero.

if (!p)
  blah = *p

The load of *p might happen before the code to check that p is
nonzero with -fsched-spec-load-dangerous.

Also note that the -fsched-reverse-{R,S} are for testing purposes
only, they actually pessimize code in an attempt to test the
scheduler more fully.  Long term I expect to rip them out of the
scheduler.

Jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> 
> So, how about this:
> 
> static rtx
> move_insn (insn, last)
>      rtx insn, last;
> {
>   while (SCHED_GROUP_P (insn))
>     {
>       rtx prev = PREV_INSN (insn);
>       move_insn1 (insn, last);
>       reemit_notes (insn, insn);
>       insn = prev;
>     }
> 
>   move_insn1 (insn, last);
>   return reemit_notes (insn, insn);
> }

I think you won't get the right return value. You want to return the
last insn in a SCHED_GROUP or a note that was placed after it.
I had my reasons to use two loops ;)

The whole affair with SCHED_GROUP_P is extremely messy. How about using
extra data structures that describe which insns to schedule together,
which notes to put before them, and the dependencies between them,
instead of trying to encode it all in the RTL with the confusion that
results?
If you don't want that, changing the meaning of SCHED_GROUP_P for the
Haifa scheduler so that it is set if the _following_ insn must be
scheduled together with an insn might make the code clearer. I think it
would fit in better with the fact that Haifa schedules forward. I didn't
try it, though; maybe there are problems with that approach, too.

Bernd

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970821173718.733B-100000@maigret.informatik.rwth-aa
chen.de>you write:
  > I've thought about something like this, but this code won't work, I think.
  > It will call reemit_notes twice for the last insn in the SCHED_GROUP and
  > not at all for the first one.
OK.  Let's use the same example again:

Consider if we have Z <-A <-B <-C, all with SCHED_GROUP_P set on A B & C,
but not Z.



  insn = C
  We start the while loop (SCHED_GROUP_P (C) == 1)
    prev = B
    move_insn1 (C, last)
    insn = B
   2nd iteration (SCHED_GROUP_P (B) == 1)
    prev = A
    move_insn1 (B, last)
    insn = A
   3rd iteration (SCHED_GROUP_P (A) == 1)
    prev = Z
    move_insn_1 (A, last)
    insn = Z
   loop terminates (SCHED_GROUP_P (Z) == 0)

  move_insn1 (Z, last)
  reemit_notes (Z, Z)


So the problem here is we don't call reemit_notes for A B & C.


So, how about this:

static rtx
move_insn (insn, last)
     rtx insn, last;
{
  while (SCHED_GROUP_P (insn))
    {
      rtx prev = PREV_INSN (insn);
      move_insn1 (insn, last);
      reemit_notes (insn, insn);
      insn = prev;
    }

  move_insn1 (insn, last);
  return reemit_notes (insn, insn);
}



  insn = C
  We start the while loop (SCHED_GROUP_P (C) == 1)
    prev = B
    move_insn1 (C, last)
    reemit_notes (C, C)
    insn = B
   2nd iteration (SCHED_GROUP_P (B) == 1)
    prev = A
    move_insn1 (B, last)
    reemit_notes (B, B)
    insn = A
   3rd iteration (SCHED_GROUP_P (A) == 1)
    prev = Z
    move_insn1 (A, last)
    reemit_notes (A, A)
    insn = Z
   loop terminates (SCHED_GROUP_P (Z) == 0)


  move_insn1 (Z, last)
  reemit_notes (Z, Z)


Jeff

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970822131829.1049C-100000@kojak.informatik.rwth-aac
hen.de>you write:
  > > So we end up moving one insn more than we should right?
  > 
  > No.
  > `SCHED_GROUP_P (INSN)'
  >      During instruction scheduling, in an insn, indicates that the
  >      previous insn must be scheduled together with this insn.  This is
  >      used to ensure that certain groups of instructions will not be
  >      split up by the instruction scheduling pass, for example, `use'
  >      insns before a `call_insn' may not be separated from the
  >      `call_insn'.  Stored in the `in_struct' field and printed as `/s'.
  > 
  > This means that the first insn in a SCHED_GROUP doesn't have the
  > SCHED_GROUP_P bit set, so Z _is_ supposed to be scheduled. The group
  > consists of all four insns.
You are absolutely correct.  My mistake.

  > I didn't make any notes, unfortunately.  I can certainly try it, but
  > I doubt it will work.
Don't bother to try it.  It's obviously wrong.

  > I'll re-run c-torture with the unmodified scheduler and
  > report all failures.
Please do.  It'll make tracking these things down easier.

Thanks,
jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> Good point.  However, the more I look at that SCHED_GROUP_P loop,
> the more I think it must be broken.
> 
> Consider if we have Z <-A <-B <-C, all with SCHED_GROUP_P set on A B & C,
> but not Z.
> 
>   insn = C
>   We start the while loop (SCHED_GROUP_P (A) == 1)
>     prev = B
>     move_insn1 (C, last)
>     insn = B
>    2nd iteration (SCHED_GROUP_P (B) == 1)
>     prev = A
>     move_insn1 (B, last)
>     insn = A
>    3rd iteration (SCHED_GROUP_P (A) == 1)
>     prev = Z
>     move_insn_1 (A, last)
>     insn = Z
>    loop terminates (SCHED_GROUP_P (Z) == 0)
> 
>   move_insn1 (Z, last)
>   
>   
> So we end up moving one insn more than we should right?

No.
`SCHED_GROUP_P (INSN)'
     During instruction scheduling, in an insn, indicates that the
     previous insn must be scheduled together with this insn.  This is
     used to ensure that certain groups of instructions will not be
     split up by the instruction scheduling pass, for example, `use'
     insns before a `call_insn' may not be separated from the
     `call_insn'.  Stored in the `in_struct' field and printed as `/s'.

This means that the first insn in a SCHED_GROUP doesn't have the
SCHED_GROUP_P bit set, so Z _is_ supposed to be scheduled. The group
consists of all four insns.

> static rtx
> move_insn (insn, last)
>      rtx insn, last;
> {
> 
>   while (SCHED_GROUP_P (PREV_INSN (insn)))
>     {
>       rtx prev = PREV_INSN (insn);
>       move_insn1 (insn, last);
>       reemit_notes (insn, insn);
>       insn = prev;
>     }
> 
>   move_insn1 (insn, last);
>   return reemit_notes (insn, insn);
> }

Apart from what I said above, that might move insns that belong to a
SCHED_GROUP that starts before insn.

> Can you try it?  Or give me the testcase that's currently failing
> for you so that I can try it myself?

I didn't make any notes, unfortunately.  I can certainly try it, but
I doubt it will work.  I'll re-run c-torture with the unmodified
scheduler and report all failures.

Bernd

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970821173718.733B-100000@maigret.informatik.rwth-aa
chen.de>you write:
  > I've thought about something like this, but this code won't work, I think.
  > It will call reemit_notes twice for the last insn in the SCHED_GROUP and
  > not at all for the first one. I've tried thinking of ways to use just one
  > loop, but they all had problems with putting all notes in the right places.
Good point.  However, the more I look at that SCHED_GROUP_P loop,
the more I think it must be broken.

Consider if we have Z <-A <-B <-C, all with SCHED_GROUP_P set on A B & C,
but not Z.



  insn = C
  We start the while loop (SCHED_GROUP_P (A) == 1)
    prev = B
    move_insn1 (C, last)
    insn = B
   2nd iteration (SCHED_GROUP_P (B) == 1)
    prev = A
    move_insn1 (B, last)
    insn = A
   3rd iteration (SCHED_GROUP_P (A) == 1)
    prev = Z
    move_insn_1 (A, last)
    insn = Z
   loop terminates (SCHED_GROUP_P (Z) == 0)

  move_insn1 (Z, last)
  
  
So we end up moving one insn more than we should right?

Seems to me move_insn should look like this:

static rtx
move_insn (insn, last)
     rtx insn, last;
{

  while (SCHED_GROUP_P (PREV_INSN (insn)))
    {
      rtx prev = PREV_INSN (insn);
      move_insn1 (insn, last);
      reemit_notes (insn, insn);
      insn = prev;
    }

  move_insn1 (insn, last);
  return reemit_notes (insn, insn);
}


Can you try it?  Or give me the testcase that's currently failing
for you so that I can try it myself?

Jeff

Re: Some Haifa scheduler bugs

[Bernd Schmidt]

> Specific questions/comments:
> 
> In move_insn, is there some reason why you can't call reemit_notes
> during the loop on SCHED_GROUP_P insns?
> 
> ie, does this work instead?  Seems cleaner than using another loop
> if it works.
> 
> {
>   rtx new_last = insn;
> 
>   while (SCHED_GROUP_P (insn))
>     {
>       rtx prev = PREV_INSN (insn);
>       move_insn1 (insn, last);
>       reemit_notes (insn, insn);
>       insn = prev;
>     }
> 
>   move_insn1 (insn, last);
>   return reemit_notes (new_last, new_last);
> }

I've thought about something like this, but this code won't work, I think.
It will call reemit_notes twice for the last insn in the SCHED_GROUP and
not at all for the first one. I've tried thinking of ways to use just one
loop, but they all had problems with putting all notes in the right places.

Bernd

Re: Some Haifa scheduler bugs

[Jeffrey A Law]

  In message <Pine.SOL.3.90.970819092828.291B-100000@starsky.informatik.rwth-aa
chen.de>you write:
  > I've run c-torture on the egcs snapshot, using the Haifa scheduler with
  > all flags turned on. My system is an i586-linux one. Here's a patch to fix
  > some of the failures.
Thanks.

Just some comments:

  * Get a copyright assignment + disclaimer signed and sent to
  the FSF as soon as possible.  Until that time we can't take any
  of your patches and include them without rewriting them first.

  * When submitting patches, send separate patches for bugs from
  random cleanups.  The cleanups are greatly appreciated, especially
  for haifa.

  * When submitting bugfix patches, please submit a testcase, or
  refer us to a c-torture testcase and the options needed to expose
  the bug.


Specific questions/comments:

In move_insn, is there some reason why you can't call reemit_notes
during the loop on SCHED_GROUP_P insns?

ie, does this work instead?  Seems cleaner than using another loop
if it works.

{
  rtx new_last = insn;

  while (SCHED_GROUP_P (insn))
    {
      rtx prev = PREV_INSN (insn);
      move_insn1 (insn, last);
      reemit_notes (insn, insn);
      insn = prev;
    }

  move_insn1 (insn, last);
  return reemit_notes (new_last, new_last);
}

[ Of course if you had referred us to a testcase, we could check
  this ourselves.... ]

Jeff

Some Haifa scheduler bugs

[Bernd Schmidt]

I've run c-torture on the egcs snapshot, using the Haifa scheduler with
all flags turned on. My system is an i586-linux one. Here's a patch to fix
some of the failures.

There seems to be at least one additional problem, which I haven't really
investigated yet. It appears as if the scheduler extends the lifetime of
hard registers, which is deadly on SMALL_REGISTER_CLASSES machines. More
specifically, the broken code looks like this:

	call somefunction
	do a multiplication; clobbers eax
	movl eax,ebx

while the correct code moves eax to ebx directly after the call. I have not
found any code in either haifa-sched.c or sched.c to prevent this problem,
so it's quite possible that the normal scheduler may also suffer from this.

	* haifa-sched.c (target_bb, bbset_size, dom, prob, rgn_nr_edges,
	rgn_edges, edgeset_size, edge_to_bit, pot_split, ancestor_edges):
	Make static.
	(move_insn): Call reemit_notes for every insn in a SCHED_GROUP.
	(schedule_block): When checking whether an insn is the 
	basic_block_head of a different block, use the first insn in the
	same SCHED_GROUP instead of the insn itself.
	(debug_dependencies): GET_RTX_NAME takes an rtx code, not an rtx.

*** haifa-sched.c.orig-1	Mon Aug 18 13:03:47 1997
--- haifa-sched.c	Mon Aug 18 21:00:48 1997
*************** int *bblst_table, bblst_size, bblst_last
*** 626,632 ****
  #define SRC_PROB(src) ( candidate_table[src].src_prob )
  
  /* The bb being currently scheduled.  */
! int target_bb;
  
  /* List of edges.  */
  typedef bitlst edgelst;
--- 626,632 ----
  #define SRC_PROB(src) ( candidate_table[src].src_prob )
  
  /* The bb being currently scheduled.  */
! static int target_bb;
  
  /* List of edges.  */
  typedef bitlst edgelst;
*************** void debug_candidates PROTO ((int));
*** 642,652 ****
  typedef bitset bbset;
  
  /* Number of words of the bbset.  */
! int bbset_size;
  
  /* Dominators array: dom[i] contains the bbset of dominators of
     bb i in the region.  */
! bbset *dom;
  
  /* bb 0 is the only region entry */
  #define IS_RGN_ENTRY(bb) (!bb)
--- 642,652 ----
  typedef bitset bbset;
  
  /* Number of words of the bbset.  */
! static int bbset_size;
  
  /* Dominators array: dom[i] contains the bbset of dominators of
     bb i in the region.  */
! static bbset *dom;
  
  /* bb 0 is the only region entry */
  #define IS_RGN_ENTRY(bb) (!bb)
*************** bbset *dom;
*** 657,663 ****
  
  /* Probability: Prob[i] is a float in [0, 1] which is the probability
     of bb i relative to the region entry.  */
! float *prob;
  
  /*  The probability of bb_src, relative to bb_trg.  Note, that while the
     'prob[bb]' is a float in [0, 1], this macro returns an integer
--- 657,663 ----
  
  /* Probability: Prob[i] is a float in [0, 1] which is the probability
     of bb i relative to the region entry.  */
! static float *prob;
  
  /*  The probability of bb_src, relative to bb_trg.  Note, that while the
     'prob[bb]' is a float in [0, 1], this macro returns an integer
*************** float *prob;
*** 669,684 ****
  typedef bitset edgeset;
  
  /* Number of edges in the region.  */
! int rgn_nr_edges;
  
  /* Array of size rgn_nr_edges.    */
! int *rgn_edges;
  
  /* Number of words in an edgeset.    */
! int edgeset_size;
  
  /* Mapping from each edge in the graph to its number in the rgn.  */
! int *edge_to_bit;
  #define EDGE_TO_BIT(edge) (edge_to_bit[edge])
  
  /* The split edges of a source bb is different for each target
--- 669,684 ----
  typedef bitset edgeset;
  
  /* Number of edges in the region.  */
! static int rgn_nr_edges;
  
  /* Array of size rgn_nr_edges.    */
! static int *rgn_edges;
  
  /* Number of words in an edgeset.    */
! static int edgeset_size;
  
  /* Mapping from each edge in the graph to its number in the rgn.  */
! static int *edge_to_bit;
  #define EDGE_TO_BIT(edge) (edge_to_bit[edge])
  
  /* The split edges of a source bb is different for each target
*************** int *edge_to_bit;
*** 687,696 ****
     the split edges of each bb relative to the region entry.
  
     pot_split[bb] is the set of potential split edges of bb.  */
! edgeset *pot_split;
  
  /* For every bb, a set of its ancestor edges.  */
! edgeset *ancestor_edges;
  
  static void compute_dom_prob_ps PROTO ((int));
  
--- 687,696 ----
     the split edges of each bb relative to the region entry.
  
     pot_split[bb] is the set of potential split edges of bb.  */
! static edgeset *pot_split;
  
  /* For every bb, a set of its ancestor edges.  */
! static edgeset *ancestor_edges;
  
  static void compute_dom_prob_ps PROTO ((int));
  
*************** build_control_flow ()
*** 1277,1284 ****
  /* construct edges in the control flow graph, from 'source' block, to
     blocks refered to by 'pattern'.  */
  
! static
! void 
  build_jmp_edges (pattern, source)
       rtx pattern;
       int source;
--- 1277,1283 ----
  /* construct edges in the control flow graph, from 'source' block, to
     blocks refered to by 'pattern'.  */
  
! static void
  build_jmp_edges (pattern, source)
       rtx pattern;
       int source;
*************** move_insn (insn, last)
*** 6512,6520 ****
        move_insn1 (insn, last);
        insn = prev;
      }
- 
    move_insn1 (insn, last);
!   return reemit_notes (new_last, new_last);
  }
  
  /* Return an insn which represents a SCHED_GROUP, which is
--- 6511,6524 ----
        move_insn1 (insn, last);
        insn = prev;
      }
    move_insn1 (insn, last);
!   while (insn != new_last)
!     {
!       rtx next = NEXT_INSN (insn);
!       reemit_notes (insn, insn);
!       insn = next;
!     }
!   return reemit_notes (insn, insn);
  }
  
  /* Return an insn which represents a SCHED_GROUP, which is
*************** schedule_block (bb, rgn, rgn_n_insns)
*** 6840,6848 ****
  	      /* an interblock motion? */
  	      if (INSN_BB (insn) != target_bb)
  		{
  		  if (IS_SPECULATIVE_INSN (insn))
  		    {
- 
  		      if (!check_live (insn, INSN_BB (insn), target_bb))
  			{
  			  /* speculative motion, live check failed, remove
--- 6844,6853 ----
  	      /* an interblock motion? */
  	      if (INSN_BB (insn) != target_bb)
  		{
+ 		  rtx tmp;
+ 
  		  if (IS_SPECULATIVE_INSN (insn))
  		    {
  		      if (!check_live (insn, INSN_BB (insn), target_bb))
  			{
  			  /* speculative motion, live check failed, remove
*************** schedule_block (bb, rgn, rgn_n_insns)
*** 6861,6878 ****
  		  nr_inter++;
  
  		  /* update source block boundaries */
  		  b1 = INSN_BLOCK (insn);
! 		  if (insn == basic_block_head[b1]
  		      && insn == basic_block_end[b1])
  		    {
! 		      emit_note_after (NOTE_INSN_DELETED, basic_block_head[b1]);
  		      basic_block_end[b1] = basic_block_head[b1] = NEXT_INSN (insn);
  		    }
  		  else if (insn == basic_block_end[b1])
  		    {
! 		      basic_block_end[b1] = PREV_INSN (insn);
  		    }
! 		  else if (insn == basic_block_head[b1])
  		    {
  		      basic_block_head[b1] = NEXT_INSN (insn);
  		    }
--- 6866,6886 ----
  		  nr_inter++;
  
  		  /* update source block boundaries */
+ 		  tmp = insn;
+ 		  while (SCHED_GROUP_P (tmp))
+ 		    tmp = PREV_INSN (tmp);
  		  b1 = INSN_BLOCK (insn);
! 		  if (tmp == basic_block_head[b1]
  		      && insn == basic_block_end[b1])
  		    {
! 		      emit_note_after (NOTE_INSN_DELETED, insn);
  		      basic_block_end[b1] = basic_block_head[b1] = NEXT_INSN (insn);
  		    }
  		  else if (insn == basic_block_end[b1])
  		    {
! 		      basic_block_end[b1] = PREV_INSN (tmp);
  		    }
! 		  else if (tmp == basic_block_head[b1])
  		    {
  		      basic_block_head[b1] = NEXT_INSN (insn);
  		    }
*************** debug_dependencies ()
*** 7383,7389 ****
  				 NOTE_SOURCE_FILE (insn));
  		    }
  		  else
! 		    fprintf (dump, " {%s}\n", GET_RTX_NAME (insn));
  		  continue;
  		}
  
--- 7391,7397 ----
  				 NOTE_SOURCE_FILE (insn));
  		    }
  		  else
! 		    fprintf (dump, " {%s}\n", GET_RTX_NAME (GET_CODE (insn)));
  		  continue;
  		}