14 Nov
2003
14 Nov
'03
7:21 a.m.
On Fri, 2003-11-14 at 12:33, Hans Franke wrote:
Am 14 Nov 2003 21:05 meinte Fred N. van Kempen:
The big problem is the code expansion, but some compilers (at suitably
high optimization levels) will do loop unrolling. To see why compilers
don't do this take a look at the implementation of memcpy in glibc.
There are *a lot* of cases to handle. Most of the time the compiler
writers just let the runtime/intrinsics deal with those cases rather
than trying to figure out how to make the code generator "do the right
thing".
Actually most compilers still do a pretty poor job of optimization and
the windows they use for peep-hole optimization appears to be way too
small to do anything really useful.
--
TTFN - Guy
On Fri, 14 Nov 2003, Hans Franke wrote:
Would be great, I still haven't seen one like that.
And just let me guess, it'll replace it by a REP STOSB,
and not use STOSW or try to allign the REP to 16 Bit borders...
BTW: above example is exactly one thing why I
hate C.
basicly every compiler will generate a stupid loop, while
in assembly a REP STOSW would do the trick at maximum
speed possible.
Thats why we invented code peeking and code optimiziers,
Hans. A decent optimizer for x86 *will* know to replace
that loop with a REP-prefixed instruction.