News for hackers. Stuff that matters.
Re:Benchmarking C++ Allocators by jlebar on Monday April 27, 2020 @07:05PM (#23001220)
> 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?
Re:Benchmarking C++ Allocators by jepler on Monday April 27, 2020 @08:20PM (#23001894)
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.

https://godbolt.org/z/U5VGxt

Without cheating:

https://godbolt.org/z/rzcXg2

It doesn't optimize the two stores to b away.

Re:Benchmarking C++ Allocators by gpderetta on Monday April 27, 2020 @08:41PM (#23002020)
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.