[llvm] r212249 - [x86] Based on a long conversation between myself, Jim Grosbach, Hal

[Chandler Carruth]

On Thu, Jul 3, 2014 at 4:24 AM, Andrea Di Biagio <andrea.dibiagio at gmail.com>
wrote:

> With your change, if we widen the vector type, then we introduce more
> elements in the vector; that means, if the type was used by a
> ISD::SHL/SRL/SRA, we are potentially introducing a longer chain of
> scalar shifts.
>
> Example 1.
> -----
> define <2 x i32> @test1( <2 x i32> %A, <2 x i32> %B) {
>   %1 = lshr <2 x i32> %A, %B
>   ret < 2 x i32> %1
> }
>
> [Without AVX2]
> Before this change, type <2 x i32> was promoted to <2 x i64>. The
> logical shift was then scalarized into a sequence of  2 'shrq'.
> If we widen the vector from <2 x i32> to <4 x i32> the shift is now
> scalarized into a worse longer sequence of 4 'shrl'.
>
> Example 2.
> ----
>
> define <2 x i32> @test2( <2 x i32> %A, <2 x i32> %B) {
>   %1 = ashr <2 x i32> %A, %B
>   ret < 2 x i32> %1
> }
>
> [Without AVX2]
> Similar to Example 1.
> We end up with a longer scalar sequence of 'sarl' instructions.
>

We shouldn't end up with these extra shifts, because the "widened" inputs
are undef, and the DAG combiner should get a chance to delete them. If it
doesn't today, I think that's the bug and it should be fixed.


However, currently, it may be hard to see this for the noise. Currently,
the vector operation legalization framework doesn't even really attempt to
do an intelligent job of legalizing vector operations when doing so
requires something other than naive scalarization. I'm working on that
right now, but it's a pretty substantial change -- it essentially is
implementing promotion rules from the type legalization engine in the
vector operation legalization engine.

There are essentially piles of places right now where widening causes us to
blindly scalarize. =/ But I agree with you that if we can fix those (and
fix the few other oddities like the shift one) the results should be quite
a bit nicer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140703/d229e744/attachment.html>