Re: Bug in haifa scheduler ?

[Jeffrey A Law <law at cygnus dot com>]

  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.

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.


jeff