This is the mail archive of the
mailing list for the GCC project.
Re: 3.0.1 Freeze
- To: Mark Mitchell <mark at codesourcery dot com>
- Subject: Re: 3.0.1 Freeze
- From: Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>
- Date: Tue, 7 Aug 2001 21:34:26 +0200
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- References: <email@example.com>
On Tuesday 07 August 2001 20:49, Mark Mitchell wrote:
> > 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.)
But this is only the simplified code, in reality we have a macro:
#define PTRRELOC(x) ((typeof(x))((unsigned long)(x) + offset))
#define RELOC(x) (*PTRRELOC(&(x)))
offset = get_reloc_offfset();
I don't see anything illegal/undefined/unportable about that code, just
plain C pointer arithmetic to implement a poor mans relocation in early boot
> 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.