Re: 3.0.1 Freeze

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot 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();
strcpy(dest, RELOC("test"));

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 
code.

> 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.

Hmm...

> 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.

Franz.