Re: Bug in haifa scheduler ?

[Gabriel Paubert <paubert at iram dot es>]

On 28 Jun 1998, Richard Henderson wrote:

> In article <Pine.HPP.3.96.980627022254.29572D-100000.cygnus.egcs.bugs@gra-ux1.iram.es>,
> Gabriel Paubert <paubert@iram.es> wrote:
> >> 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.
> 
> Not good enough.  The thing is, marking an asm as clobbering memory
> also acts as a kind of synchronization point, forcing gcc to drop
> pending writes to memory.
> 
> Why, you ask, isn't a volatile memory reference good enough?  Because
> a volatile memory reference does _not_ mean that the write will be
> done immediately.  Rather it means that it will not be elided nor
> reordered with respect to other memory references.
> 
> So by eliding the memory clobber, you are telling gcc that memory
> references may be moved across this asm with impunity.

Sorry for being dense but I do not understand at all your point. I only
care that the compiler respects the order of volatile references and asm
volatile statements. I don't care at all if the compiler wants to
move around the references to local and global variables or even remove
or optimize them to outside loops or whatever it wants.

Can you think of an example to clarify things ?

And BTW, I'm running a kernel compiled with modified io.h (not a single
'memory' clobber) without any problems. I know it's not a proof, however
(but I've recompiled it several times on a machine with 16Mb which
thrashes a lot).

But I have added an "m" (*addr) or "=m" (*addr) to little endian 16 and 
32 bit i/o references (big endian and byte versions explicitly dereference
a pointer to volatile). And the expansion in the RTL is: 

(insn/i 137 136 139 (set (mem/v:SI (plus:SI (reg/v:SI 82)
                (reg:SI 117)))
        (asm_operands/v ("stwbrx %1,0,%2") ("=m") 0[ 
                (reg:SI 114)
                (reg/v:SI 115)
            ] 
            [ 
which seems to indicate that the compiler realizes that we are accessing
volatile memory. Even the volatile in the asm is probably overkill but 
I did not dare to remove it.  

There are still optimization problems, though. The compiler seems to
reload isa_io_base too often. I'm trying to understand why...  It could
perhaps be declared as a constant since it is only initialized on boot
(and a few others), so there is only one place where we would have play
tricks around the compiler and this is before starting the kernel proper,
in the very early boot. 

> >> 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.
> 
> I've always thought there should be a way that a particular target
> could add builtin functions of its own, so as to expose some bit of
> target-specific wierdness.  If this were done, the builtin expander
> might be able to massage the memory reference in the first place.
> 
> Not that I know what "Altivec code" code is, but it is just a thought.
> 

Its the equivalent of MMX or VIS for PPC. Note that about memory
addressing modes, I've not yet understood anything besides the 'm'
constraint. 'o', 'V' and others remain mysterious. 

	Gabriel.