-minline-all-stringops
By default GCC inlines string operations only when destination is
known to be aligned at least to 4 byte boundary. This enables more
inlining, increase code size, but may improve performance of code
that depends on fast memcpy, strlen and memset for short lengths.
So I guess it's alignment, not the fact the size is variable? This
type of pattern could hurt MSVC, where it usually inlines the memcpy
as a rep movsd, rep movsb. So now we're going to generate code for
two mostly identical copy looks, then branch to pick one.
On Wed, Oct 8, 2008 at 12:58 PM, Erik Corry <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Oct 8, 2008 at 12:10 PM, Dean McNamee <[EMAIL PROTECTED]> wrote:
>>
>> Won't memcpy always be an inlined intrinsic?
>
> Not with variable size:
>
> $ cat copy.cc
> #include <string.h>
>
> extern void foo(char* a, char* b, int size) {
> memcpy(a, b, size);
> }
> $ g++ -S -O3 copy.cc
> $ cat copy.s
> .file "copy.cc"
> .text
> .align 2
> .globl _Z3fooPcS_i
> .type _Z3fooPcS_i, @function
> _Z3fooPcS_i:
> .LFB2:
> pushl %ebp
> .LCFI0:
> movl %esp, %ebp
> .LCFI1:
> popl %ebp
> jmp memcpy
> .LFE2:
> .size _Z3fooPcS_i, .-_Z3fooPcS_i
> .ident "GCC: (GNU) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)"
> .section .note.GNU-stack,"",@progbits
>
>
>
>
>>
>> On Wed, Oct 8, 2008 at 10:38 AM, Kevin Millikin <[EMAIL PROTECTED]>
>> wrote:
>>> LGTM.
>>>
>>> On Wed, Oct 8, 2008 at 10:31 AM, <[EMAIL PROTECTED]> wrote:
>>>>
>>>> Reviewers: Kevin Millikin,
>>>>
>>>> Description:
>>>> Minor adjustments to the object migration code: When copying
>>>> large objects we use memcpy. If this turns out to be a wash
>>>> on the benchmarks, I'd be happy to rip it out again.
>>>>
>>>> Please review this at http://codereview.chromium.org/6576
>>>>
>>>> Affected files:
>>>> M src/heap.cc
>>>>
>>>>
>>>> Index: src/heap.cc
>>>> ===================================================================
>>>> --- src/heap.cc (revision 465)
>>>> +++ src/heap.cc (working copy)
>>>> @@ -733,11 +733,21 @@
>>>> int size) {
>>>> void** src = reinterpret_cast<void**>((*source_p)->address());
>>>> void** dst = reinterpret_cast<void**>(target->address());
>>>> - int counter = size/kPointerSize - 1;
>>>> - do {
>>>> - *dst++ = *src++;
>>>> - } while (counter-- > 0);
>>>>
>>>> + // Use block copying memcpy if the object we're migrating is big
>>>> + // enough to justify the extra call/setup overhead.
>>>> + static const int kBlockCopyLimit = 16 * kPointerSize;
>>>> +
>>>> + if (size >= kBlockCopyLimit) {
>>>> + memcpy(dst, src, size);
>>>> + } else {
>>>> + int remaining = size / kPointerSize;
>>>> + do {
>>>> + remaining--;
>>>> + *dst++ = *src++;
>>>> + } while (remaining > 0);
>>>> + }
>>>> +
>>>> // Set the forwarding address.
>>>> (*source_p)->set_map_word(MapWord::FromForwardingAddress(target));
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Google Denmark ApS
>>> CVR nr. 28 86 69 84
>>> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen
>>> K,
>>> Denmark
>>>
>>> >
>>>
>>
>> Google Denmark ApS. CVR nr. 28 86 69 84
> c/o Philip & Partners, 7 Vognmagergade, P.O. Box 2227, DK-1018 Copenhagen K,
> Denmark.
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---
