Bug in haifa scheduler ?

Jeffrey A Law law@cygnus.com
Fri Jun 26 16:52:00 GMT 1998


  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



More information about the Gcc-bugs mailing list