[llvm-commits] [PATCH] - Instcombine vector code optimizations

[Rotem, Nadav]

Hi Dan, 

Thanks for the quick reply. 

1. If ExtractElem has only one user, then Yes. However, it's not always profitable to break vector casts to multiple scalar casts. Conversions such as i32->float should stay in vector form. I am not sure about vector Zext/Sext/Trunc. I worked on workloads on which the codegen did a better job scalarizing the casts. Generally the GEP optimization is very profitable on my programs. I plan to experiment with other patterns as well.

2. Unlike the GEP optimization, I have not seen real-life workloads which benefit from this optimizations. However, adding support for these vector types to the existing optimization was tempting enough to give it a try. The attached LL test has several cases which do get optimized thanks to this optimization.
 
I agree that in some cases this optimization may propagate illegal code. I just want to point that the same thing can be said about vectorizing compilers which may generate illegal vector types. I had a discussion with Duncan on making changes to the legalizer in order to support strange types such as <4 x i36> and the infamous <4 x i1> type. Duncan had a plan. In short, he proposed to generalize getTypeAction and getTypeToTransformTo, have them work with a different enum, the enum in LegalizeTypes.h (LegalizeAction). I intend to start working on in next week. I will write you once I have a better understanding of things there.

Should I commit ?

Thanks,
Nadav


-----Original Message-----
From: Dan Gohman [mailto:gohman at apple.com] 
Sent: Thursday, April 07, 2011 18:54
To: Rotem, Nadav
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] [PATCH] - Instcombine vector code optimizations


On Apr 7, 2011, at 4:24 AM, Rotem, Nadav wrote:

> Hi, 
> 
> Please review the attached patch. I implemented two main optimizations:
> 
> 1. Getelementptr (PTR, extract (vcast)))  -> Getelementptr (PTR, cast (extract)))  scalarize the casting of pointer index. 
>   This generates much better code in cases where the gep index comes from a vector. 

This seems unrelated to getelementptr.  Isn't cast(extract(x)) better than
extract(vcast(x)) on its own?

> 2. Extend the EvaluateInDifferentType and CanEvaluateXXX to support Extract/Insert/ShuffleElement instructions.

This seems a bit precarious since LLVM doesn't know what vector types
and operations are "legal", and since Codegen's "legalizer" only works
locally, so it can't fully recover if expression trees cross basic block
boundaries.

Dan

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.