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

Quentin Colombet qcolombet at apple.com
Fri Jan 16 14:20:49 PST 2015


+Chandler

On Jan 16, 2015, at 1:57 PM, Fiona Glaser <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.

> 
>> 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 :).

> 
>> 4. Add a run line for avx  too:
>> +; RUN: llc < %s -march=x86-64 -mattr=+avx2 | FileCheck %s
> 
> Done.
> 
>> 5. Should we use a triple instead of march?
> 
> Do triples let you specify particular attributes (AVX, etc?)

Yes, they do. Their use is recommended when we check for instructions that may change because of the ABI. This is not the case here or if it is, like Eric pointed out, this is bad :).

Q.

> 
> Fiona
> 
> 
> <patch.diff>
> 

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


More information about the llvm-commits mailing list