[LLVMbugs] [Bug 20830] New: std::vector ctor for POD type from pointer range results in horrible codegen

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20830

            Bug ID: 20830
           Summary: std::vector ctor for POD type from pointer range
                    results in horrible codegen
           Product: libc++
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: arseny.kapoulkine at gmail.com
                CC: llvmbugs at cs.uiuc.edu, mclow.lists at gmail.com
    Classification: Unclassified

Created attachment 12970
  --> http://llvm.org/bugs/attachment.cgi?id=12970&action=edit
Full disassembly for the problematic code

Using clang from Xcode 6 Beta 3:
Apple LLVM version 6.0 (clang-600.0.38) (based on LLVM 3.5svn)

Compiling the following code:

std::vector<char> build(const char* data, size_t size) { return
std::vector<char>(data, data + size); }

Results in the assembly with *this* as an inner loop (clang++ -O3):

LBB0_5:                                 ## =>This Inner Loop Header: Depth=1
    testq    %rcx, %rcx
    movl    $0, %eax
    je    LBB0_7
## BB#6:                                ##   in Loop: Header=BB0_5 Depth=1
    movb    (%rbx), %al
    movb    %al, (%rcx)
    movq    8(%r14), %rax
LBB0_7:                                 ##
%_ZNSt3__116allocator_traitsINS_9allocatorIcEEE9constructIccEEvRS2_PT_RKT0_.exit.i.i.i
                                        ##   in Loop: Header=BB0_5 Depth=1
    incq    %rax
    movq    %rax, 8(%r14)
    incq    %rbx
    decq    %r15
    movq    %rax, %rcx
    jne    LBB0_5

With -stdlib=libstdc++ I get "callq _memcpy" instead.

Changing libc++ sources to hoist __end_ into a local does not help very much -
it removes redundant load/store instructions for __end_ but the loop is still
there.

Also I'm not sure why "decq %r15" is here - as far as I can see compiler should
have removed it. Can someone confirm that this part looks like a separate
optimization issue and warrants filing a separate LLVM bug?

Full disassembly dump attached.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140902/b2293f0e/attachment.html>