Re: Bug in haifa scheduler ?

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

Am Sat, 27 Jun 1998 schrieb Gabriel Paubert:
>On Fri, 26 Jun 1998, Jeffrey A Law wrote:
>
>> 
>>   In message <Pine.HPP.3.96.980627010141.29572C-100000@gra-ux1.iram.es>you write:
>>   > > >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/O access. 
>> But without the "memory" in the asm the compiler doesn't know that the
>> changes memory and thus the compiler decides it is safe (for example)
>> to hold a value that was loaded from memory in a register across the
>> asm statement.
>
>That's exactly what I want (unless there is a misunderstanding somewhere). 
>Most I/O instructions do not have side effect on variables (local and
>global) kept in registers, they simply should be treated as an access to
>volatile memory.
>
>> 
>> You can't have it both ways -- either you have to describe all these
>> side effects to the assembler to prevent mis-optimization or you can't
>> optimize in the presense of asm instructions at all.
>> 
>>   > 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):  
>> That's going to be extremely difficult/impossible to implement.  I wouldn't
>> recommend it.
>> 
>> Basically reload doesn't know how to turn a general memory reference
>> into an indexed address.  So, if for some reason you didn't get an
>> indexed memory address reload will not know how to fix things.
>
>Ok, so we'll have to write almost all Altivec code in assembly ;).  But
>let me suggest another solution: that the inw and outw instructions be
>written this way (assuming unsigned short data, volatile unsigned short *
>port):
>
>- for inw:
>	asm("lhbrx %0,0,%1" : "=r" (data): "r" (port), "m" (*port));
>
>- for outw:
>	asm("sthbrx %1,0,%2" : "=m" (*port): "r" (data), "r" (port));
>
>in both cases one the parameter wit the "m" constraint is not used in the
>asm statement but it should not matter. My understanding is that the
>compiler will accept this code and does not care about one of the
>parameters not being used. Furthermore, it should not allocate any
>additional registers for the "m" constraint given the "r" (port) 
>constraint. Essentially the "m" constraint means that we are accessing
>volatile memory, the other ones describe how it is implemented. 
>
>Would this work ?

I think this is not enough. The eieio (Old MacDonald had a farm, I love this
instruction :-))  ) instruction (if we want to avoid the general memory 
clobber for in/out's) has to be integrated into the in/out volatile asm,
otherwise it can again be reordered around the in/out's by the compiler, which
is not what we want.

So it should look something like that:

outw():
asm volatile("eieio; sthbrx %1,0,%2" : "=m" (*port): "r" (data), "r" (port));

inw():
asm volatile("eieio; lhbrx %0,0,%1" : "=r" (data): "r" (port), "m" (*port));


And for eieio() uses indepedent of the in/out inlines we should keep the
general memory clobber.

eieio():
asm volatile("eieio" : : : "memory");

Franz.