[llvm-commits] [PATCH] - Instcombine vector code optimizations
gohman at apple.com
Tue Apr 12 15:45:17 PDT 2011
On Apr 7, 2011, at 12:34 PM, Rotem, Nadav wrote:
> 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.
Sorry for the late reply. I don't have time to review this further,
so I'll just post what I know and let you make an educated judgement
about what to do.
Most of LLVM's major SIMD users are not public, so it's hard to
get broadly representative workloads.
Instcombine doesn't currently know what types and operations are
legal on the target. In contrast, vectorizers (human, compiler, and
hybrid) are essentially required to know a fair amount about the
target, because that's the only way to know what's going to be
worthwhile. Legalize may be able to help out more, but even then,
it won't be able to do everything. Under these circumstances,
instcombine should err on the side of trusting the vectorizer,
esepcially when it comes to things like folding casts through
On that note, it's worth understanding why your vectorizer is
producing Getelementptr (PTR, extract (vcast))) in the first place.
More information about the llvm-commits