|
From: | address@hidden |
Subject: | Re: [lwip-devel] [PATCH] Fix aliasing violation. |
Date: | Fri, 03 Oct 2008 17:09:23 +0200 |
User-agent: | Thunderbird 2.0.0.17 (Macintosh/20080914) |
David Woodhouse wrote:
This isn't a question of broken compilers: It's a code size vs. speed question (an optimized memcpy is much bigger than a simple for-loop that does a byte copy). If the compiler decides not to inline, it would call 'memcpy'. And since on most platforms, memcpy is a generic implementation of a C-library which is NOT optimized for the actual hardware, an assembly-routine can be much faster.On Fri, 2008-10-03 at 16:43 +0200, address@hidden wrote:In 1.3.0, we converted all calls to 'memcpy' to either 'MEMCPY' or 'SMEMCPY' (s for short). The goal is optimization: SMEMCPY is defined to memcpy (which the compiler may inline e.g. if size is known at compile time and small); whil MEMCPY can be overridden to provide a better copy mechanism (on my platform, for example, copying non-aligned data can be solved much better when loading full words and shifting in registers).Therfore, using 'memcpy' directly should be avoided: when you know your compiler can't optimize it, you can redefine SMEMCPY to inlining yourself.I'm inclined to suggest that the correct answer in that case is to _fix_ the compiler, not work around it. But OK...
SMEMCPY was chosen to explicitly state this is a short memcpy and we (lwIP developers) don't want to call the fast routine for it since the compiler might optimize it.
Simon
[Prev in Thread] | Current Thread | [Next in Thread] |