Re: Bug in haifa scheduler ?

[rth at cygnus dot com (Richard Henderson)]

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.

>> 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.


r~