<div dir="ltr"><div dir="ltr"><div><div><div><div><div><div><div><div><div>It is pretty clear people need this. Let's get this moving.<br><br></div>I'll try to sum up the point that have been made and I'll try to address them carefully.<br></div><br>1/ There is no good solution for large aggregates.<br></div>That
 is true. However, I don't think this is a reason to not address smaller
 aggregates, as they appear to be needed. Realistically, the proportion 
of aggregates that are very large is small, and there is no expectation 
that such a thing would map nicely to the hardware anyway (the hardware 
won't have enough registers to load it all anyway). I do think this is 
reasonable to expect a reasonable handling of relatively small 
aggregates like fat pointers while accepting that larges ones will be 
inefficient.<br><br></div><div>This limitation is not unique to the current discussion, as SROA suffer from the same limitation.<br></div><div>It
 is possible to disable to transformation for aggregates that are too 
large if this is too big of a concern. It should maybe also be done for 
SROA.<br></div><div><br></div>2/ Slicing the aggregate break the semantic of atomic/volatile.<br></div>That
 is true. It means slicing the aggregate should not be done for 
atomic/volatile. It doesn't mean this should not be done for regular 
ones as it is reasonable to handle atomic/volatile differently. After 
all, they have different semantic.<br><br></div>3/ Not slicing can create scalar that aren't supported by the target. This is undesirable.<br></div>Indeed. But as always, the important question is compared to what ?<br><br></div>The
 hardware has no notion of aggregate, so an aggregate or a large scalar 
ends up both requiring legalization. Doing the transformation is still 
beneficial :<br></div> - Some aggregates will generate valid scalars. For such aggregate, this is 100% win.<br><div><div><div><div><div><div><div><div> -
 For aggregate that won't, the situation is still better as various 
optimization passes will be able to handle the load in a sensible 
manner.<br></div><div> - The transformation never make the situation worse than it is to begin with.<br><br></div><div>On previous discussion, Hal Finkel seemed to think that the scalar solution is preferable to the slicing one.<br><br></div><div>Is that a fair assessment of the situation ? Considering all of this, I think the right path forward is :<br></div><div> - Go for the scalar solution in the general case.<br></div><div> - If that is a problem, the slicing approach can be used for non atomic/volatile.<br></div><div> - If necessary, disable the transformation for very large aggregates (and consider doing so for SROA as well).<br><br></div><div>Do we have a plan ?<br></div><div><br></div></div></div></div></div></div></div></div></div></div>