[llvm-commits] PATCH: A new SROA implementation

[Eli Friedman]

On Tue, Aug 21, 2012 at 12:57 AM, Chandler Carruth <chandlerc at gmail.com> wrote:
> I'm inclined to completely remove this transform. It seems fundamentally
> unsafe given the current spec of GEPs, and provides fairly limited benefit
> if the frontend consistently lowers to insertelement and extractelement
> (which it did in most of my experiments). If we want to support this
> transform, I think we need to either extend GEP to have an optional
> constraint on inbounds indexing within array and/or vector aggregates, or we
> need to change the semantics of the existing 'inbounds' keyword to mean
> that.

That sounds right.

>>
>>
>> I'm sort of worried about allowing SROA so much freedom in terms of
>> splitting memset/memcpy; your algorithm can turn a single memcpy into
>> an arbitrary number of memcpys (which is a quadratic explosion in
>> codesize in the worst case).  Not sure if it's an issue in practice.
>
>
> Yes, this is the primary concern with the new algorithm. That said, the N*M
> which explodes requires N overlapping splittable operations which overlap
> with M disjoint un-splittable operations. My hope is that this latice
> structure is very rare. Even better, whenever we start heavily splitting,
> we're getting something out of it -- we're successfully isolating
> un-splittable partitions which should form candidates for promotion.
>
> Do you have any ideas for mitigating or bounding the growth that don't
> devolve to heuristics?

Hmm... I can't think of anything.  As far as I can tell, it's
basically a tradeoff between codesize and the number of memory
accesses, and there isn't any clear place to draw the line.

-Eli