[X86, AVX] adjust tablegen patterns to generate better code for scalar insertion...
authorSanjay Patel <spatel@rotateright.com>
Thu, 2 Apr 2015 17:56:17 +0000 (17:56 +0000)
committerSanjay Patel <spatel@rotateright.com>
Thu, 2 Apr 2015 17:56:17 +0000 (17:56 +0000)
commit8765e82c83eca2fc7527d5a5a494d83d2432d430
treef62df360758ae5c5f946f57af2e27a9c63a1e7aa
parente1aa33fb9a8055cc30658f1ff984dddc38966bb0
[X86, AVX] adjust tablegen patterns to generate better code for scalar insertion into zero vector (PR23073)

For code like this:

define <8 x i32> @load_v8i32() {
  ret <8 x i32> <i32 7, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0, i32 0>
}

We produce this AVX code:

_load_v8i32:                            ## @load_v8i32
  movl $7, %eax
  vmovd %eax, %xmm0
  vxorps %ymm1, %ymm1, %ymm1
  vblendps $1, %ymm0, %ymm1, %ymm0 ## ymm0 = ymm0[0],ymm1[1,2,3,4,5,6,7]
  retq

There are at least 2 bugs in play here:

    We're generating a blend when a move scalar does the same job using 2 less instruction bytes (see FIXMEs).
    We're not matching an existing pattern that would eliminate the xor and blend entirely. The zero bytes are free with vmovd.

The 2nd fix involves an adjustment of "AddedComplexity" [1] and mostly masks the 1st problem.

[1] AddedComplexity has close to no documentation in the source.
The best we have is this comment: "roughly corresponds to the number of nodes that are covered".
It appears that x86 has bastardized this definition by inflating its values for some other
undocumented reason. For example, we have a pattern with "AddedComplexity = 400" (!).

I searched my way to this page:
https://groups.google.com/forum/#!topic/llvm-dev/5UX-Og9M0xQ

Differential Revision: http://reviews.llvm.org/D8794

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233931 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Target/X86/X86InstrSSE.td
test/CodeGen/X86/vector-shuffle-256-v4.ll
test/CodeGen/X86/vector-shuffle-256-v8.ll