[PATCH] Improve DAG combine pass on certain IR vector patterns

[Fiona Glaser]

> On Jan 16, 2015, at 2:20 PM, Quentin Colombet <qcolombet at apple.com> wrote:
> 
> +Chandler
> 
> On Jan 16, 2015, at 1:57 PM, Fiona Glaser <fglaser at apple.com <mailto:fglaser at apple.com>> wrote:
> 
>> > 1. Run your patch through clang-format please. The patch does not follow the LLVM formatting guidelines.
>> 
>> Done, and changed per Mehdi’s suggestions.
>> 
>> > 2. What is the impact of this on arm64 and armv7s generated code? Although the approach makes sense to me, I want to be sure we do not degrade other targets. Note that I do not expect you to run tests if you cannot :).
>> 
>> I don’t think it should even affect any target that doesn’t have canonical vector sizes of both N and 2*N, for a data type of N/2 or smaller. Otherwise the case this patch targets can’t come up.
> 
> I do not quite follow the condition on the data type, but regarding the vector sizes, for instance, both v2i32 and v4i32 are legal IIRC on ARM, which would indicate that the optimization can kick in there, unless I am missing something of course.

The case comes up when you have a concat of two vectors of size N/2, creating a vector of size N, which is then concerted with undef to create a 2*N vector.

I figure it -should- at least help if it somehow did come up on ARM, since it effectively converts 128-bit shuffles to 64-bit shuffles in that case.

> 
>> 
>>> 3. What are the runtime performance impact on x86_64, with and without -mavx2?
>> 
>> I’m not sure in general; this affects a few very specific vector constructs that were being pessimized.
> 
> Right, but I would have liked some empirical evidences. Sometimes we have surprises with our lowering even when the IR/DAG is supposed to be better :).

I’m new to this; what’s the typical way of demonstrating this? I tried the llvm external test suite but the test noise is vastly too high to make solid conclusions about performance.

Fiona
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150116/a6732e64/attachment.html>