llvm: Fix alloca alignment and type selection in AllocOpt

[gbaraldi]

Inherit alignment from the original GC allocation with JL_SMALL_BYTE_ALIGNMENT
as the minimum. Use alignment-sized integer chunks for the alloca type
(matching emit_static_alloca) so SROA splits allocations into aligned pieces
for better performance and vectorization.

Also adds the missing setAlignment call in splitOnStack.

Co-Authored-By: Claude Opus 4.5 noreply@anthropic.com

[vtjnash]

This feels loosely unsound, since this is the minimum known alignment, and not the required alignment. The JL_SMALL_BYTE_ALIGNMENT value is the largest value that julia.gc_alloc_obj is permitted to return, so it is sometimes reasonable that we can use this as a hint, but we should be sure to clarify that this overalignment is merely a hint to the layout (although being more than 16 will penalize performance since it requires a more expensive stack adjustment on entry)

    (unsigned)orig_inst->getRetAlign().valueOrOne().value()

[gbaraldi]

But if the allocation required a larger alignment wouldn't we inherit that, that's why we prefer to inherit and just baseline to gc align

[vtjnash]

getRetAlign is not the required alignment, it is the minimum, so if it requires it, this would introduce a bug here

but that said, the function isn't capable of giving more than JL_SMALL_BYTE_ALIGNMENT (16) so having getRetAlign return more than 16 here would be a miscompile, so this always gives the correct answer anyways (and increasing from there is only a runtime performance penalty, not a correctness issue)

[gbaraldi]

It’s the alignment we emitted no? If it required more it would already be a bug no? Unless you mean a gc alloc aligned that wouldn’t tell LLVM

[vchuravy]

cc: @maleadt

This might cause issues for the intel backend? If I recall correctly, they don't like i128?

[oscardssmith]

Pretty sure Our Int128 emits i128.

[gbaraldi]

So this i128 should be storage only most of the time, I just followed whatever we do for base Julia