Update: Clang now identifies that the return value is 10! Funnily enough, if you don’t specify v.reserve(4), you still get an allocation, but the allocation is totally unused. It calls operator new, then operator delete, then returns 10.
Maybe you should create even more flags for the compiler. Not to throw all of them at the user's face, but to have flags that can "unlock" new options/flags, if the user is trying to go deeply in optimization. Just an idea.
Exactly! No one who actually cares about performance would expect the compiler to magically fix this kind of stuff. There is a finite time budget for optimizations, and it should not be spent on trying to mend such obivously-pessimized code.
Optimizer indeed should be able to optimize out such a trivial example with literal input in the program source etc. But what's the point? In reality, such examples probably show up only in some simple toy-benchmarks.
I don't see why the compiler would be expected to optimize that out. Sure, the return value is one thing but someone may actually want the heap allocation side effects
@@abuyoyo31 Potentially there could be an sbrk or mmap call done by malloc which would be optimized out. But relying on that behavior here would be more than a little crackpot
Wow: thanks for the amazing shout out for Compiler Explorer :)
Moral: run your optimizer repeatedly until the code is optimized enough ;)
Update: Clang now identifies that the return value is 10!
Funnily enough, if you don’t specify v.reserve(4), you still get an allocation, but the allocation is totally unused. It calls operator new, then operator delete, then returns 10.
Did you know that searching for "the number of inlining shall be three" finds Monty Python videos, not this one?
Maybe you should create even more flags for the compiler. Not to throw all of them at the user's face, but to have flags that can "unlock" new options/flags, if the user is trying to go deeply in optimization.
Just an idea.
I really like Chandler Carruth's talks.
I like the idea of the optimiser going out to launch 😆
here's how you optimize for less alllocations: don't write code that does many allocations
Exactly! No one who actually cares about performance would expect the compiler to magically fix this kind of stuff. There is a finite time budget for optimizations, and it should not be spent on trying to mend such obivously-pessimized code.
Optimizer indeed should be able to optimize out such a trivial example with literal input in the program source etc. But what's the point? In reality, such examples probably show up only in some simple toy-benchmarks.
I don't see why the compiler would be expected to optimize that out. Sure, the return value is one thing but someone may actually want the heap allocation side effects
>want the heap allocation side effects
That's horrible!
Then pass in the vector, or use gcc. Better yet, become a hair stylist.
"want the heap allocation side effects"
You can turn off optimization. But regardless, I think you're doing programming wrong.
The vector in this particular code snippet is destroyed upon function exit. There is no such side effect.
@@abuyoyo31 Potentially there could be an sbrk or mmap call done by malloc which would be optimized out. But relying on that behavior here would be more than a little crackpot
Soooo basically it is a rant because the compiler doesn't *acually* runs your code and hard-code into resulting executable? .. interesting
Why should this be optimized? It shouldn't.