Ok, I think this patch is pretty close to being ready to go into the tree, modulo any detailed code review folks are willing to do. Just send me comments if you have them.<div><br></div><div>I've run it through the nightly test suite now as well as a bootstrap, and everything looks better than clear, it looks great. ;]</div>
<div><br></div><div>I'm seeing some pretty significant execution performance improvements. One test is 27% faster, several range from 2% to 6% faster. Only a couple really slow down. I haven't dug in to the performance too much as currently we're still running the old SROA in the CGSCC passes.</div>
<div><br></div><div>I've still got some code cleanup, minor refactorings I'd like to do, and the SSAUpdater work, but I'm trying to not grow the patch on people.</div><div><br></div><div>-Chandler<br><div><div>
<br><div class="gmail_quote">On Tue, Aug 21, 2012 at 6:26 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@gmail.com" target="_blank">chandlerc@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<div class="HOEnZb">
<div class="h5"><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>On Tue, Aug 21, 2012 at 12:57 AM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" target="_blank">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><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><font color="#888888"><br>
-Eli<br>
</font></span></blockquote></div><br>
</div></div></blockquote></div><br></div></div></div>