(patch) hpjyg09: bcache optimizations

[Jim Blandy]

> 	While it is true that it is not tied to the microprocessor,
> (and the placement of the macro is not ideal perhaps,) it is tied 
> somewhat to the HP-UX platform in that :

Ahh.  That, I didn't know.  So it would be correct to put the flag in
a file associated with a particular toolchain.

> 	o The bcache is beneficial, when there is high degree of
>           duplication and redundancy in the debug info generated
>           by a set of compilers for a platform (e.g : stabs + gcc + linux.)
> 
>         o and is useless and high overhead item , if there is little
>           or no duplication (e.g : som + HP cc + HP-UX).
> 
> 
> 	On HP-UX systems, we have a tool called pxdb, which is a linker
> post processor (or a debugger preprocessor if you want to look at it 
> that way) which runs thro the a.out and removes all duplicates. So when
> gdb enters the picture there is no duplicate debug info at all. Further 
> this overhead is not particular to the C compiler, it is seen for all
> applications compiled with HP compilers. The C compiler's case just
> happened to be mentioned. That we waste 140 MB trying to eliminate the 
> non-existent dups was a big concern for us.	

It's a big concern for us, too --- I'll explain why.

The memory consumed by the bcache depends only on the number of unique
strings it contains --- not on the presence or absence of duplicates.
Using pxdb has no effect on the amount of bcache memory overhead.  So
if HP is having problems with bcache memory overhead, others will have
problems, too.

It's not a toolchain-specific problem.  But disabling it is a
toolchain-specific fix.