[cfe-dev] missing optimization opportunity for const std::vector compared to std::array

Gabriel Dos Reis gdr at integrable-solutions.net
Thu Jun 5 03:33:06 PDT 2014


On Thu, Jun 5, 2014 at 3:01 AM, Dennis Luehring <dl.soluz at gmx.net> wrote:

> Am 31.05.2014 16:14, schrieb Marshall Clow:
>
>> > but i do not understand why its so hard to track overridden allocations
>> - or why
>> > they can't be removed - in the end there is an malloc/free or
>> __builtin_operator_new/delete
>>
>> Well, consider the following code:
>>
>>         int * foo () { return new int; }
>>
>> Does that call the default operator new?
>> Or some overridden one?
>>
>
> and why is then clang 3.4.1
> even without Richard Smith latest patch with __builtin_operator_new/delete
> allowed to remove this new?
>
> #include <memory>
>
> int main()
> {
>   return *new int(10);
> }
>
> clang 3.4.1, -O3 -std=c++11
>
> main:                                   # @main
>     movl    $10, %eax
>     ret
>
> gcc 4.9.0 20130909, -O3 -std=c++11
>
> main:
>     subq    $8, %rsp
>     movl    $4, %edi
>     call    operator new(unsigned long)
>     movl    $10, (%rax)
>     movl    $10, %eax
>     addq    $8, %rsp
>     ret
>

GCC's codegen could be improved.  However, Clang's appears to be a little
be too eager and potentially non-legit.  E.g. it is legit if that
translation unit is the only unit of the entire program.  However, it isn't
if that translation unit was linked with another unit providing a
replacement for 'operator new'.  This is something that LTO could handle
very well.


-- Gaby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140605/49e26108/attachment.html>


More information about the cfe-dev mailing list