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]
Other format: [Raw text]

Re: [tree-ssa] fix opt/13798

> On Wed, Jan 28, 2004 at 04:21:17PM -0800, Richard Henderson wrote:
> > I don't believe this is correct in general.
> Nevermind, you're looking at MEM_EXPR.  I'll have to think about
> it to see if there are any other gotchas.

Actually, there appears to be a problem with if-conversion.
This not taking the address of the variable is only true at
a semantic level, but not necessarily at the RTL level, when the
processor can't put a SYMBOL_REF into a memory access instruction.
Consider this function:

g (int a)
  static int a, b;

  a = 1;
  f ();
  b = 2;
  return c ? a : b;

If the return statement is optimized with if-conversion, the MEM_EXPR
remaining might not be for b.  Then the scheduler could move the load
before the store to b.

We can fix this either by

- Not using this information after if-conversion - AFAICT the most
  interesting optimization that can use the information is load
  hoisting / store sinking during loop optimization.
  AFAICR cross-jumping is done even later.  Are there other optimizers
  we would have to worry about?


- Make sure that when on optimizer merges two memory accesses, it shows
  all the original MEM_EXPRs which relate to static variables in the
  new MEM_EXPR.  E.g. it could gather them in a PARALLEL.
  nonoverlapping_memrefs_p would then have to check not only for
  equality of the two MEM_EXPRS, but also if the MEM_EXPR which it has
  determined to belong to a non-adressed, static variable is mentioned
  in a PARALLEL in the other expression.

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