there's a lot I don't understand about optimizers, but is it unreasonable to expect a modern C++ compiler to turn foo() into an add instruction?
13
10
51
Conversation
Replying to
"std::vector<int> v {a, b}" seems to make a huge difference with gcc trunk. But still not a simple add. godbolt.org/z/DDrOCO
1
8
In general, I don't think either Clang or GCC is capable of getting rid of malloc/free or new/delete outside of a special case for completely dead stores. They aren't capable of doing escape analysis and lowering it to a stack allocation / virtual registers so it won't go away.
2
1
They're happy to get rid of them in cases where doing do is an invalid transformation, like p=malloc(-1); if(p) puts("bad"); free(p);
1
1
In general, they make up their own semantics for C standard library functions. A good example is that Clang doesn't support floating point rounding modes or signalling NaN. It explicitly chooses to implement optimizations incompatible with an implementation of those features.
1
1
GCC has -frounding-math -fsignaling-nans to make those work, but Clang just doesn't implement it. Another example is Clang optimizing out calls to pure functions even if they would have never returned. They don't have an always_return attribute yet but do the optimization anyway.
1
2
For their virtual definition of malloc used by the optimizer, it's allowed to be treated as if it may always succeed and is also treated as having no external side effects outside the program. Neither of those is really true, but that's the C virtual machine they implement.
2
In theory, what they implement is the C virtual machine defined by the standard, but the standard is buggy and incomplete. Rather than being conservative, they stretch the meaning of ambiguous / vague wording to fit their very subjective decisions about what should be allowed.