• Since the removal of typed pointers, there has been increasingly little meaning to the alloca element type, and some passes that cannot accurately preserve this element type at all. • There are many parallels here between GEP vs ptradd, under the opaque pointer scheme, so I don’t want to repeat all of that discussion and will instead point to https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699 and https://discourse.llvm.org/t/rfc-de-type-ification-of-llvm-ir-why/88257 . • Notably, the mere existence of the alloca element type adds awkward complications to passes like SROA and MemCpyOpt, even though they just fallback to byte arrays anyways, so byte array support is already required everywhere. • I would like to propose that LLVM discard this legacy function in favor of making an alloca simply a byte-sized object (actually an optional, preserving scalable ability, to be precise). • In legacy terms, I propose that all alloca would become arrays like so: alloca i8, i64 %N or alloca < 1 x i8 x vscale>, i64 imm %N , with getAllocatedType returning i8 (until deleted) and isArrayAllocation returning true (until deleted). • The proposed IR would be something like alloca i64 %N, align M or alloca vscale x i64 , align N , once the transition period is complete.

Article Summaries:

Sources: