This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Fix 20000724-1.c

>>>>> "Richard" == Richard Henderson <> writes:

    >>  Sorry, I don't understand.  Can you expand on this?

    Richard> Suppose that the asm doesn't clobber memory.  Suppose
    Richard> that it reads it and copies it into magic device
    Richard> registers or something else the compiler doesn't know or
    Richard> care about.

    Richard> In which case there would be no need for the "memory"
    Richard> clobber.

I'm still being dense.

In this test-case, if there was no overwriting of the memory, things
would work OK.

What I'm trying to say is that if there were no writes to memory, then
moving the stack pointer around would be harmless; that doesn't change
memory.  It's the pushes that clobber the local variable.

So, that's why I was saying we could avoid the bug by not combining
across a memory clobber.  I thought you said that was either too
conservative, or not conservative enough -- but I'm not sure which,
and I'm still not sure why.

    Richard> As for rationale, a volatile asm is already treated
    Richard> specially in that it is a scheduling barrier.  If a
    Richard> non-volatile asm was used in the original test case, it's
    Richard> likely to fail *even without* the stack pointer
    Richard> combination -- the epilogue instruction to deallocate the
    Richard> stack frame could just as easily be scheduled in front of
    Richard> the asm, because there is no knowledge of the dependancy.

That seems like a bug to me.  The volatile bit should be used to
indicate, as documented in the manual, that "this instruction has
weird side-effects", which means don't delete it, and don't reorder
it, and not much more.

Oh, I take it back.  This sentence:

  If the side-effects of your instruction are not purely external, but
  will affect variables in your program in ways other than reading the
  inputs and clobbering the specified registers or memory, you should
  write the `volatile' keyword to prevent future versions of GNU CC
  from moving the instruction around within a core region.

seems to imply that just about nothing should happen across a volatile
asm.  In fact, that sentence seems to say that a volatile asm can mess
with anything it wants without having anything in its clobbers at all!
I think a literal reading of that sentence means that clobbers on a
volatile asm have no semantics; even if you leave out the clobbers the
compiler must assume that the side-effects "will affect variables in
your program" which sounds like just about everything to me.

Can you clarify this point, and I can try to clean up the
documentation?  My guess is that if I don't fully get it, non-GCC
developers are totally lost.

Mark Mitchell         
CodeSourcery, LLC     

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]