Adding llvm-dev to this thread as this is probably worth wider discussion. See the original patch email below.
If you’re sending just code-related comments, consider dropping llvm-dev.
- It splits based the underlying type of the alloca, regardless of how the alloca is accessed.
Next let's talk about splitting based on the underlying type. What happens with C++ unions? Bad code. ;] In many cases, one side of the union ends up getting nuked as dead code, and by only attending to the *use* of the memory, we catch this by >>design. Another interesting aspect of designing the analysis around the *use* of the memory is that it suddenly applies equally well to malloc'ed memory.
FWIW, SROA has been a problem that Hexagon has grappled with for a while.
For instance, code such as
union 64bit {
double x;
int y[2];
short int z[4];
};
SROA converts this into a 64 bit scalar.
Now, if there are regions where only the 16 bit member is accessed then insert_16_bits_into_64 and extract_16_bits_from_64 semantics are needed. Whereas, the 16 bit operations could have been more efficiently done in 32 bits.
Pranav
Qualcomm Innovation Center, (QuIC) is a member of the Code Aurora Forum.