Re: Bug in haifa scheduler ?

[Gabriel Paubert <paubert at iram dot es>]

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 ?

	Gabriel.