[PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os

[Paul Mackerras]

Kumar Gala writes:

> We'll hopefully this thread might spark either an explanation for why  
> we aren't just linking libgcc in a statement that says we should and  
> we can remove the code that implements libgcc functionality.

I've just reviewed the code in the 32-bit and 64-bit PowerPC versions
of libgcc.  It's pretty huge (half a megabyte or so in total) but
fortunately most of the bulk is in the decimal floating-point support,
which I largely ignored (though I did notice in passing that it calls
libc functions including strchr, strtof, and sprintf).

On 64-bit I don't see anything there that I would expect we would
need.  There are some things that are in there because some processors
have particular instructions that others don't, for example popcountb
(which is in the V2.05 architecture but not earlier versions), so gcc
can generate either the instruction or a call to the libgcc function,
depending on what sort of processor you're compiling for.  However, in
those cases, we'd want our own version of the libgcc function so that
we could use our CPU feature mechanism to give us the new instruction
on those CPUs that have it.

On 32-bit, it's pretty much just the 64-bit arithmetic routines that
we would need from libgcc (shifts, compares, multiply, divide,
modulo).  I'm not too impressed with the quality of the code there,
for example, the 64-bit signed divide routine is 299 instructions,
which seems enormous to me.  It's all generated from portable C code
by gcc.  I think I can do a smaller and faster 64-bit divide routine
in assembler, for instance.

So on the whole I don't think we want to link with libgcc, although I
don't feel very strongly about it.

Paul.