Since my branches are part of a fork, I've created a PR comparing this one and the array removal PR immediately before it here: pchintalapudi#5

cc: @chriselrod

Marking as draft because #43487, #43547, #43384, and #43548 are all still under review.

I think I've squashed that bug and a few others now, and slightly upgraded the stack allocation process itself. Do you think you could try again now @chriselrod? Just as a note, arrays of references aren't currently being stack allocated because I haven't figured out how to make stack allocation play nicely with the garbage collector yet.

I think I've squashed that bug and a few others now, and slightly upgraded the stack allocation process itself. Do you think you could try again now @chriselrod? Just as a note, arrays of references aren't currently being stack allocated because I haven't figured out how to make stack allocation play nicely with the garbage collector yet.

The vectors contain structs wrapping UInt8. They're isbits.
However, these vectors are held in structs themselves.
There was another issue where IIRC you and others said this may cause issues with the escape analysis?

I see no difference in allocations.

I tried the code here to resolve TTFP in #43725.
It works well: the allocation disappeared and LLVM properly generated simd IR.
(For comparasion, MArray version failed to vectoralize.)
I only have one problem: is it a must to force inlining all the call on "small array"?
During my trial, even a copyto! will block the optimization.

This seems stalled, but it's really cool, can we push this through the goal line?

This also need some examples / benchmarks to show the effect.

We have abandoned this work for now in order to focus on some other work. There were some correctness concerns around the changes in alloc-opt IIRC.