Skip initialization of Pointer.malloc with zero value

[straight-shoota]

Implements #16203 (comment)

Pointer.malloc initializes the allocated memory with zeros, so we can skip the explicit implementation if the representation of value is all zeroes.

This should make Pointer(T).malloc(size, value) (almost) as efficient as Pointer(T).malloc(size) when value is all zeros.

[ysbaddaden]

For the record:

Pointer.malloc initializes the allocated memory with zeros...

... if we required src/gc.cr to define __crystal_malloc64 that will call the GC that will zero the allocation (be it gc/boehm or gc/none). Otherwise the compiler calls LibC.malloc and the memory is uninitialized 🤷

Now, that's a very edge case and we probably don't need to care about it.

[HertzDevil]

This edge case is present in all codegen specs that do not require the prelude (in fact I believe __crystal_malloc64 was invented precisely for reducing boilterplate in them). Still this is only relevant if a spec tries to require pointer.cr directly I guess?

[ysbaddaden]

@HertzDevil Yes, that's why I brought it up, but the compiler specs load the whole prelude when they need something from stdlib, and never load src/pointer.cr directly or indirectly.

Still, we might want to check for {% if @toplevel.has_constant?(:GC) %}.

[straight-shoota]

We were discussing potential changes to memory allocation characteristics to more explicitly handle when memory needs to be zeroed out and when not (#14687 and #14677).
So potentially there might be changes in the future. But in the current state of things, it should be assumed that Pointer.malloc allocates zeroed memory. We even do that explicitly in gc_none.

[ysbaddaden]

Yeah, it's a real edge case. It only happens when you manually require src/pointer.cr and don't require src/gc.cr and don't have a custom __crystal_malloc64 (or one that doesn't zero)... which neither of the compiler specs or even nanolib do, so... it's definitely fine 👍

[straight-shoota]

Merged master with #16338 and resolved conflict