This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH, i386]: Do not emit "cld" instructions

On 12/4/06, Jan Hubicka <> wrote:

As author of the current cld emitting code, I can just say that I kept
it around for single reason, that the old GCC always emitted it and I
didn't find any specification in the 32bit ABI (in 64bit ABI we specify
CLD as clear and I did have patch to disable CLD codegen there that
probably got lost somewhere on it's way to mainline).   Other minor
reason for me was that we never specified if the asm inline blocks are
required to cld after std, but as Michael correctly observed, there is
very little need for this.

I was also originally thinking about memmove inline expander, but it
don't seem that important to me (since we don't really want to copy
backwards anyway, we probably might want to inline memmove internally in
a way checking that blocks don't overlap in negative direction and are
small and use our memcpy inliners, emitting library call otherwise)

I would not be oposed to not emitting it at all - it just never seemed
important enought for me as it is short and rather fast on most modern
CPUs.  It seems better alternative to me than introducing the mode
switching pass that has some compilation time implications.

Based on all comments and suggestions, I'd propose that we keep all cld functionality, but emit empty asm instead of "cld". If gcc ever emits std instruction, we could re-enable cld and perhaps emit it via optimize mode switching.

A comment in front of cld insn pattern hopefully clarifies this situiation.

Also note that CSE/GCSE is currently pretty capable on eliminating many
redundant CLDs.

Unfortunatelly, for some reasons clds were not eliminated from loops...

> > Finally, according to pentium optimization guide by Agner Fog, std and
> > cld have astonishing latency of 48 and 52 clks (I still hope for the
> > possibility that there is some kind of error).

This is prety weird. Does this apply to original Pentium?

According to the guide, it applies to pentium4.

2006-12-06 Uros Bizjak <>

* config/i386/ (cld): Emit empty asm string.

Patch was bootstrapped on i686-pc-linux-gnu, regression tested for c,
c++ and fortran.

OK for mainline?


Attachment: i386-nocld.diff
Description: Binary data

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]