Re: Bug in haifa scheduler ?

[Gabriel Paubert <paubert at iram dot es>]

On Fri, 26 Jun 1998, Franz Sirl wrote:

> Usually happens to people who upgrade from 2.1.24 and don't have the new
> major/minors for clock/adb/etc. yet.
> 
> >> following patch for io.h:
> >> 
> >> Index: io.h
> >> ===================================================================
> >> RCS file: /cvsroot/linux/include/asm-ppc/io.h,v
> >> retrieving revision 1.29
> >> diff -u -r1.29 io.h
> >> --- io.h        1998/06/23 20:06:13     1.29
> >> +++ io.h        1998/06/23 23:15:44
> >> @@ -202,7 +202,7 @@
> >>   */
> >>  extern inline void eieio(void)
> >>  {
> >> -       asm volatile ("eieio" : :);
> >> +       __asm__ __volatile__ ("eieio" : : : "memory" );
> >>  }
> >>  
> >>  /*
> >> 
> >> 
> >> Hope this helps,
> >
> >
> >What worries me is that a memory clobber effectively disables many 
> >optimizations. All I/O macros use pointers to volatile or volatile
> >asm statements, and I thouht that these would already prevent the compiler
> >from  reordering but allow it to keep values in register across the
> >I/O access. 
> 
> I'm still not sure if this is a compiler bug or a bug in the kernel. The
> documentation for "asm volatile" in my understanding states that it can be
> reordered in a block (but what is a block here?), so I tried to give the
> compiler more hints for reordering (effectively it _is_ clobbering memory)
> and suddenly it worked. I also didn't see any significant change in the
> generated code, so I thought bettter save than sorry ;-). The file in
> question is platinum.c, without this change you'll get the famous "striped
> display".

Ok, but the generated code may not be very different because some of the
"out" macros also include a "memory" clobber. The following idea may be
stupid, but I nevertheless want to explain it. 

Since a few specialized instructions of the PPC architecture, namely
l[hw]brx, st[hw]brx, l[wd]arx, st[wd]cx. and all newly announced Altivec
instructions can only access memory using the "indexed" addressing mode,
what we need is a new constraint type that forces using this mode on a
memory reference. In this case, for example the outw macro would become
essentially (I use the constraint 'Z' since it is unused for now from
a look at info gcc, I would like a better explanation of what the 'V'
constraint means BTW):  

 asm volatile("sthbrx %1,%0" : "=Z" ((unsigned short volatile *)&port) 
			     : "r" (value))

followed by an asm volatile("eieio"). 
(And why not combine both into a single statement).

This way we explicitly say the compiler that we write (or read) into a
volatile area of memory. If the compiler then reorders this, it is
definitely broken, while for now we put in a register a pointer to a
volatile but we do not explicitly tell the compiler that the pointer is
dereferenced. This might be the difference.

	Gabriel.