> even without LTO, the compiler knows what malloc and free do at a semantic level.
int *a = ...;
int b = *a;
malloc(42);
b = *a;
printf(b);
If malloc is an opaque function, can the compiler nonetheless eliminate the second `b = *a` load as dead because it "knows what malloc does"? Certainly not, right?https://godbolt.org/z/z-92qR
Interestingly, the compiler emits no call to malloc, even. What!?
Re:Benchmarking C++ Allocators
by steerablesafe on Tuesday April 28, 2020 @05:01AM
(#23005107)
With -fno-builtin. It's still "cheating" as b is local.
Without cheating:
It doesn't optimize the two stores to b away.
The compiler knows the semantics of malloc. Malloc as it appear in the source code doesn't even need to map 1:1 to calls to the library function, the compiler can remove and coalesce calls at will.
I buy the sized delete win, I’ve seen that too, in some niche cases. But that’s a far cry from the claim that not inlining malloc is bananas. If that’s all you got then this sounds like a stunning retreat from the thesis of Jeff’s post. You’re just saying that you’ve got a free that benefits from size specialization, which has nothing to do with whether malloc got inlined.