Thanks for the comments so far. Updated patch attached. Not everything is addressed, in particular some code cleanups and style fixes haven't yet happened. However, this removes the dynamic GEP handling, adds aggressive vector-typed rewriting and starts to handle lifetime intrinsics. Still no debug intrinsic handling.<br>
<br><div class="gmail_quote">On Tue, Aug 21, 2012 at 1:52 AM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, Aug 21, 2012 at 12:57 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
> I'm inclined to completely remove this transform. It seems fundamentally<br>
> unsafe given the current spec of GEPs, and provides fairly limited benefit<br>
> if the frontend consistently lowers to insertelement and extractelement<br>
> (which it did in most of my experiments). If we want to support this<br>
> transform, I think we need to either extend GEP to have an optional<br>
> constraint on inbounds indexing within array and/or vector aggregates, or we<br>
> need to change the semantics of the existing 'inbounds' keyword to mean<br>
> that.<br>
<br>
</div>That sounds right.<br>
<div class="im"><br>
>><br>
>><br>
>> I'm sort of worried about allowing SROA so much freedom in terms of<br>
>> splitting memset/memcpy; your algorithm can turn a single memcpy into<br>
>> an arbitrary number of memcpys (which is a quadratic explosion in<br>
>> codesize in the worst case).  Not sure if it's an issue in practice.<br>
><br>
><br>
> Yes, this is the primary concern with the new algorithm. That said, the N*M<br>
> which explodes requires N overlapping splittable operations which overlap<br>
> with M disjoint un-splittable operations. My hope is that this latice<br>
> structure is very rare. Even better, whenever we start heavily splitting,<br>
> we're getting something out of it -- we're successfully isolating<br>
> un-splittable partitions which should form candidates for promotion.<br>
><br>
> Do you have any ideas for mitigating or bounding the growth that don't<br>
> devolve to heuristics?<br>
<br>
</div>Hmm... I can't think of anything.  As far as I can tell, it's<br>
basically a tradeoff between codesize and the number of memory<br>
accesses, and there isn't any clear place to draw the line.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Eli<br>
</font></span></blockquote></div><br>