Poor code generation for odd sized vectors

[llvmbot]

Bugzilla Link	11023
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@bcardosolopes

Extended Description

I'm compiling LLVM IR code like this on x86-64:

  define linkonce ccc <16 x float> @vector_add_float(<16 x float>  %a.78, <16 x float>  %a.79) align 8  
  {
  entry:
    %result.80 = fadd <16 x float> %a.78, %a.79
    ret <18 x float> %result.80
  }

This works really well when the vector length (16 in the above) is an integer multiple of the SSE vector register width (4) resulting in the following assembler code:

    vector_add_float:                       # @vector_add_float
    .Leh_func_begin0:
    # BB#0:                                 # %entry
	addps	%xmm4, %xmm0
	addps	%xmm5, %xmm1
	addps	%xmm6, %xmm2
	addps	%xmm7, %xmm3
	ret

However, when the vector length is increased to say 18, the generated code is rather poor, or rather is code that could easily be improved by hand.

[llvmbot]

The problem seems to be in SelectionDAGBuilder which is scalarizing the function
arguments for some reason.

[llvmbot]

It's due to this FIXME in TargetLowering::getVectorTypeBreakdown:

  // FIXME: We don't support non-power-of-2-sized vectors for now.  Ideally we
  // could break down into LHS/RHS like LegalizeDAG does.
  if (!isPowerOf2_32(NumElts)) {
    NumVectorRegs = NumElts;
    NumElts = 1;
  }

[llvmbot]

It's due to this FIXME in TargetLowering::getVectorTypeBreakdown:

// FIXME: We don't support non-power-of-2-sized vectors for now.

So why is it non-power-of-2? Shouldn't it be non-integer-multiples of the native vector size?

[llvmbot]

It's due to this FIXME in TargetLowering::getVectorTypeBreakdown:

// FIXME: We don't support non-power-of-2-sized vectors for now.

So why is it non-power-of-2? Shouldn't it be non-integer-multiples of the
native vector size?

For example, having tested the actual implementation, it does the right thing in x86-64 for vector lengths of eg 12 (not a power of 2, but is a multiple of the vector length 4) and only produces poor results when the vector length is not an integer mutliple of the vector length.

[llvmbot]

I agree that the code in TargetLowering::getVectorTypeBreakdown doesn't make much
sense.