[LLVMdev] PATCH: A new SROA implementation

[Pranav Bhandarkar]

>>- 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.