[llvm-commits] [PATCH] Simplify ARM Neon vmull_n_* intrinsics.

[Lang Hames]

Hi Chandler,

I thought about that, but it seemed like a more disruptive change. As I
understand it, the logic in and under SimplifyMulInst assumes that the type
of the simplified expression will be the same as the type of the
operation's arguments, which isn't the case for vmull_n_* (their return
type width is twice their argument type width). Threading the desired
expression type and extension method through SimplifyMulInst and its
callees seems like it could be messy. Is there a good way to do this?

- Lang.

On Mon, Apr 23, 2012 at 11:22 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Mon, Apr 23, 2012 at 11:18 PM, Lang Hames <lhames at gmail.com> wrote:
>
>> Hi All,
>>
>> Could someone who's more familiar with InstCombine please take a look at
>> this patch for me? It's meant to enable simplification of ARM neon
>> vmull_n_* intrinsics by zext/sexting (as appropriate) their arguments so
>> that they can be analyzed with SimplifyMulInst.
>>
>
> Rather than introducing zext/sext instructions, why not teach
> SimplifyMulInst to look through the existing vmull_n_* intrinsics?
>
>
>>
>> It seems to fix my test case, but it has at least one issue: The
>> sext/zext instructions hang around after InstSimplify if the vmull isn't
>> simplified - I have to explicitly run DCE afterwards to get rid of
>> them (see the output for the complex1 function in the test case for an
>> example of this). Tips on the right way to solve this would be appreciated.
>>
>> Cheers,
>> Lang.
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120424/82726c3a/attachment.html>