[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