This is the mail archive of the
mailing list for the GCC project.
Re: 3.0.1 Freeze
- To: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Subject: Re: 3.0.1 Freeze
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 07 Aug 2001 11:49:29 -0700
- cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
> If U is used as a pointer relocation, the above is wrong, we would have
> to generate:
I'm trying to make sure I understand, so please bear with me.
I think you're saying that, here, `u' is some giant value. In other
words, you have a big table, and `test string' might be the first
string in the table. 10,000 characters later is another string, so
`u' is 10,000. And, you want to copy that later string. Right?
Well, then, writing:
"test string" + u
is undefined in C; you're indexing off the end of the array given by
"test string". (Or perhaps implementation defined? I forget.)
Anyhow, it's not portable code. So, I think you're asking us to
disable an optimization that is valid for conforming programs, so
that a non-conforming program will work. Is that right?
If I'm right so far, then we need to weigh those tradeoffs.
There's an easy work around in your code; put the address somewhere where
GCC can't see it's a string constant. For example, store the address
of the constant into a global variable. That will work until we
have brilliant cross-procedural optimizations, when we'll figure out
that it's a string constant again...
I don't think the optimization is any more or less valid for strlen
than it is for strcpy. If you asked for the length of that far-away
string, we would get the "wrong" answer for exactly the same reason.
The question is how valuable this optimization is. I don't really know.
When the optimization works, we get a faster copy because memcpy is
faster than strcpy. But, I don't imagine that very many programs
are spending their inner loops copying from string constants plus
an offset, and if they're not doing that in an inner loop, then the
optimization will make no difference, since inner loops are, roughly
speaking, all that matter.
Hmm. I see that the SGI MIPS compiler does not do this transformation.
I don't have any other compilers handy at the moment; I'd be interested
to see what they do.
My current thinking is to remove this optimization, and replace it with
a note indicating why it is not valid for "real programs", until we have
time to debate it in more detail. Perhaps it can be reeneabled in 3.1.
Other opinions would be welcome.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com