[PATCH] SROA: extract instead of shuffle when performing vector/array type punning

[JF Bastien]

On Sat, Feb 7, 2015 at 9:28 PM, Chandler Carruth <chandlerc at gmail.com>
wrote:

>
> On Sat, Feb 7, 2015 at 5:16 PM, JF Bastien <jfb at chromium.org> wrote:
>
>> Hi chandlerc, jvoung,
>>
>> The resulting code is shorter and simpler to optimize. The existing code
>> was more general, and still serves as the fallback case when the incoming
>> vector type and the outgoing scalar are incompatible. This code should
>> trigger more often than through type punning, but that's the user code I
>> saw it trigger on.
>>
>
> Not sure this is the right approach. It is a lot of complexity, and we
> still have the fallback.
>
> Have you looked at teaching instcombine to transform the code produced by
> SROA today into the element extract? That would seem a better layering at
> the least, although I'm still on the fence about whether we want to in
> general perform this operation.
>

I could teach instcombine to do this, I think the code would be about the
same, but would rely on a potentially cleaner patter match (unusual vector
shuffle followed by a bitcast to the type that was actually desired),
instead of what I have now (oh hey you're going to try to extract but I
know I'll just bitcast later, so if you could extract that would be great
thanks).

I could instead keep the code in SROA and remove the fallback and (from my
beautiful ASCII art example) return the i40 directly instead of having the
fallback. I'm just not sure this code gets hit much, so I figured
addressing the case I saw first made sense, but can address both if you
think it worthwhile.

Thoughts?

In either case I'd keep the ASCII art. We need more ASCII art.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150207/11c82d9c/attachment.html>