[PATCH, i386]: Emit cld instruction when stringops are used

Uros Bizjak ubizjak@gmail.com
Tue Apr 29 09:51:00 GMT 2008


On Mon, Apr 28, 2008 at 11:37 PM, Mark Mitchell <mark@codesourcery.com> wrote:

> I agree with Joseph as to the strategy. If there is no objection to that
> strategy, is there a patch to review?

I have different opinion on this matter, that I would like to share:

IMO, there are two classes of users, the ones that get their compiler
from their distribution and users that get the compiler from FSF
website.

1) The compiler that is provided by the distribution does not need to
be patched, since the distribution also provides relevant update to
the kernel (it is a two-line patch). Both, the patch and the compiler
are/should be patched and updated together.

2) Users that download the compiler directly do this because they have
an application they care about and they want to squeeze every bit of
performance out of this application. Even if the kernel is not updated
(please note that due to point 1) above, applications and libraries
are compiled with older gcc in this case) it is just a matter of
fixing the application, so it doesn't mess with cld anymore.

Thinking a bit about it, I come to the conclusion, that the impact of
this bug is negligible, and I propose to simple close this matter
without patching the compiler. The rationale for this proposal is,
that adding --enable-cld is not a good solution, since (a)
distributions won't need it, since thy will patch the kernel and (b)
power users won't use it, since emitting cld has non-negligible
performance impact and they will rather fix the application. Also,
adding -mcld means that we will have to carry this options far in the
future to handle 0.001% of users that want to use old kernel with
bleeding-edge compiler and don't want to bother by changing source
code of their application to comply with published ABI.

So, I don't agree that patching the compiler to emit CLD in order to
fix bugs that are elsewhere is the solution for this problem.

Uros.



More information about the Gcc-patches mailing list