[LLVMdev] Matching addsub

Duncan Sands baldrick at free.fr
Tue Oct 18 01:15:44 PDT 2011


Hi Hal, you should probably add a target specific DAG combine that
synthesizes the appropriate target instruction.  This is how I
handled x86 horizontal add (see the FHADD X86 opcode).  If it turns
out that the same thing is useful for other targets then it can be
generalized later.

Ciao, Duncan.

On 10/18/11 00:40, Hal Finkel wrote:
> How should I go about matching floating-point addsub-like vector
> instructions? My first inclination is to write something which matches
> build_vector 1.0, -1.0, and then use that in combination with a match on
> fadd, but that does not seem to work. I think this is because
> BUILD_VECTOR cannot ever be "Legal", and so it is always turned into a
> constant load before instruction selection.
>
> Specifically, in SDValue SelectionDAGLegalize::LegalizeOp(SDValue Op):
>
> case ISD::BUILD_VECTOR:
> // A weird case: legalization for BUILD_VECTOR never legalizes the
> // operands!
> // FIXME: This really sucks... changing it isn't semantically incorrect,
> // but it massively pessimizes the code for floating-point BUILD_VECTORs
> // because ConstantFP operands get legalized into constant pool loads
> // before the BUILD_VECTOR code can see them.  It doesn't usually bite,
> // though, because BUILD_VECTORS usually get lowered into other nodes
> // which get legalized properly.
> SimpleFinishLegalizing = false;
> break;
>
> and then:
>
> case ISD::BUILD_VECTOR:
>    switch (TLI.getOperationAction(ISD::BUILD_VECTOR,
> Node->getValueType(0))) {
>    default: assert(0&&  "This action is not supported yet!");
>    case TargetLowering::Custom:
>      Tmp3 = TLI.LowerOperation(Result, DAG);
>      if (Tmp3.getNode()) {
>        Result = Tmp3;
>        break;
>      }
>      // FALLTHROUGH
>    case TargetLowering::Expand:
>      Result = ExpandBUILD_VECTOR(Result.getNode());
>      break;
>    }
>    break;
> (so there is not even branch for TargetLowering::Legal). Maybe I'm just
> missing something.
>
> Thanks in advance,
> Hal
>




More information about the llvm-dev mailing list