On Fri, Jan 20, 2006 at 10:10:23AM -0500, David Edelsohn wrote:
> >>>>> Jakub Jelinek writes:
>
> Jakub> Not sure why sched allows that, because insn 42 clearly operates on
> volatile
> Jakub> memory. Do you think that's a bug in sched that it should be honoring
> Jakub> /v and not moving insns accross it, or that something is broken with
> the
> Jakub> ppc* patterns?
>
> I think it more likely is a latent bug in the scheduler, not a
> problem with the patterns. Admittedly the volatile load-locked insn does
> not appear until the post-reload splitter after sched1, but it still seems
> that the scheduler should not move volatile mem.
That's quite questionable, depends on what is a volatile memory reference
supposed to mean (and what is UNSPEC_VOLATILE supposed to mean, and __asm
__volatile).
My understanding is that UNSPEC_VOLATILE and __asm __volatile are an
optimization barrier, but a mere volatile memory reference doesn't have
to be. Other memory references obviously cannot be moved over the volatile
memory read or write if GCC can't prove they don't overlap or if they
are both volatile. But a memory read or write that provably doesn't
overlap the volatile memory location, is not volatile (thus has no
side-effects) IMNSHO can be moved across it, hoisted out of loops etc.
__sync_* builtins are supposed to be optimization barriers, so I'd say
UNSPEC_VOLATILE or some other optimization barrier for them is highly
desirable.
> What happens on Alpha? I would expect that it would show similar
> symptoms.
It is likely Alpha and IA-64 have similar problems (in fact, the number
ofunreproduceable failures I'm getting in libgomp testsuite on ia64 is quite
high, while i386, x86_64, s390{,x}, sparc* (and ppc* with the patch I
posted) are fine). But I don't have an Alpha box to check that myself.
Jakub
