This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] fix opt/13798
- From: Joern Rennecke <joern dot rennecke at superh dot com>
- To: rth at redhat dot com (Richard Henderson)
- Cc: joern dot rennecke at superh dot com (Joern Rennecke), dalej at apple dot com (Dale Johannesen), rth at atrey dot karlin dot mff dot cuni dot cz, gcc-patches at gcc dot gnu dot org, hubicka at ucw dot cz (Jan Hubicka)
- Date: Thu, 29 Jan 2004 12:35:32 +0000 (GMT)
- Subject: 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;
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.