Allocation Profiler: Types for all allocations

[NHDaly]

A variant on #50333.

Pass the types to the allocator functions.

---

Before this PR, we were missing the types for allocations in two cases:

1. allocations from codegen
2. allocations in gc_managed_realloc_

The second one is easy: those are always used for buffers, right?

For the first one: we extend the allocation functions called from codegen, to take the type as a parameter, and set the tag there.

I kept the old interfaces around, since I think that they cannot be removed due to supporting legacy code?

---

An example of the generated code:

  %ptls_field6 = getelementptr inbounds {}**, {}*** %4, i64 2
  %13 = bitcast {}*** %ptls_field6 to i8**
  %ptls_load78 = load i8*, i8** %13, align 8
  %box = call noalias nonnull dereferenceable(32) {}* @ijl_gc_pool_alloc_typed(i8* %ptls_load78, i32 1184, i32 32, i64 4366152144) #7

Fixes #43688.
Fixes #45268.

[NHDaly]

(Similar issue here, btw):

julia> using Profile
Precompiling Profile
  ✗ Profile
  0 dependencies successfully precompiled in 2 seconds
[ Info: Precompiling Profile [9abbd945-dff8-562f-b5e8-e1ebf5ef1b79]
Call parameter type does not match function signature!
  %"+Main.Base.Dict#12848" = load {}*, {}** @SUM.MainDOT.BaseDOT.DictYY.1284, align 8, !dbg Call parameter type does not match function signature!
  !269, !tbaa !233, !alias.scope !234, !noalias !237, !nonnull !0, !dereferenceable !248, !align !245
 i64  %newstruct = call noalias nonnull dereferenceable(80) {} addrspace(10)* @ijl_gc_pool_alloc_typed(i8* %ptls_load1314, i32% 17 = inttoptr i64 %Tuple1328 to {}*
 i64, i32 80, {}* nonnull %"+Main.B  a%sboxe = .callD icnoalias nonnull dereferenceable(32) {} addrspace(10)* t@#ijl_gc_pool_alloc_typed1(2i8848") #21, *! d%b21g,  i!32269 1184
, i32 32, {}* %17) #21
in function julia_Dict_1299
LLVM ERROR: Broken function found, compilation aborted!
in function jfptr_ht_keyindex2_shorthashNOT._1306
LLVM ERROR: Broken function found, compilation aborted!

EDIT: oops, previous comment was mistaken.

[NHDaly]

Aha! I fixed it with a small builder.CreatePtrToInt(tag, T_size). I'm not sure why it was needed here when it wasn't needed elsewhere.. 🤔 but it makes sense I think that it should be needed.

[NHDaly]

This PR is actually really nice and simple, and assuming I'm not missing any reason why we were setting the tag in LLVM IR, hopefully this is a nice little change that solves the profiler issue! 😊

Thanks in advance for the review! :)

[vchuravy]

@nanosoldier runbenchmarks(!"scalar", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[NHDaly]

@vchuravy: What do you make of those benchmark results? There's a surprising amount of improvements, which doesn't really make sense to me, and makes me worried that the results are just quite noisy.

There are more regressions than improvements, to be sure. The worst offender is this one:

["tuple", "reduction", ("sum", "(2,)")]        1.71 (5%) ❌	

[vchuravy]

@vchuravy: What do you make of those benchmark results? There's a surprising amount of improvements, which doesn't really make sense to me, and makes me worried that the results are just quite noisy.

There are more regressions than improvements, to be sure. The worst offender is this one:

["tuple", "reduction", ("sum", "(2,)")]        1.71 (5%) ❌	

It's pretty much just noise

[vtjnash]

@nanosoldier runbenchmarks("find", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[vchuravy]

You will also need to adjust the docs of the allocation profiler.

[NHDaly]

And fix the generated code tests, once we decide what we want the final codegen behavior to be.