Mem2Reg Alloca Promotion

Mem2Reg is advertised as a pass implementing the standard SSA construction algorithm to construct pruned SSA form, promoting alloca instructions which only have loads and stores as uses.

However, alloca instructions are promoted only if the load and store types do match.
The following function remains unchanged after running mem2reg.

define float @foo(i32 %v) {
  %retval = alloca i32
  store i32 %v, ptr %retval
  %ret = load float, ptr %retval
  ret float %ret
}

Running sroa, however, promotes the alloca by introducing a bitcast, necessary to coerce the integer into a float.

define float @foo(i32 %v) {
  %1 = bitcast i32 %v to float
  ret float %1
}

Is there a fundamental reason why mem2reg avoids inserting such coercions to enable SSA construction in cases like this?
If not, would extending mem2reg to handle these cases be beneficial?

This is an intentional split in responsibility between SROA and Mem2Reg. Mem2Reg only does pure SSA construction. SROA brings non-trivial cases into a form that Mem2Reg can handle. That includes the eponymous breaking down of aggregates, but also insertion of casts, creation of insert/extract patterns, etc.

No, this should continue to be the responsibility of SROA.

2 Likes