[LLVMdev] Vectorizer using Instruction, not opcodes

[Renato Golin]

On 4 February 2013 20:44, Arnold Schwaighofer <aschwaighofer at apple.com>wrote:

> Would a tree of <opcode, return-type, input-type>s work? How deep would it
> need to be?
>
> Agreed, if we decide on more information than just type and opcode we will
> need some abstract representation.
>

I didn't want to create yet-another-instruction-type, but I now agree
passing instruction is not an option. I think that passing a tree would be
bound to overuse, since you never know how much is enough beforehand and
passing too much will penalise the operations that didn't even need it in
the first place.

What I was thinking was something flat and target-independent, like:

enum VectFlags {
  ConstantShift = 0x0000001;
  VariableShift = 0x0000002;
  ...
  ArithmeticCast = 0x0000100;
  MemoryCast = 0x0000200;
  ...
};

and the user (vectorizers) can set a few flags where appropriate and pass
the flags (which can also be carried on, cached, stored somewhere else,
like metadata).

getCastInstructionCost(opcode, dstTy, srcTy, Flags) {

 isArith = Flags & ArithmeticCost;

  costtable = {
    { ISD::SEXT, MVT::Foo, MVT::Bar1, isArith+1 }
    { ISD::SEXT, MVT::Foo, MVT::Bar2, isArith }
    { ISD::SEXT, MVT::Foo, MVT::Bar3, 1 }
    { ISD::SEXT, MVT::Foo, MVT::Bar4, 0 }
    ...
  }

}




> > We also need to decide on some self-consistent way of dealing with cost
> folding. What I mean is that if an instruction can be folded with its use,
> do we register that cost savings for the use or the operand? We'd also need
> to pass hasOneUse() information.
>

Constant folding is a big problem per se. I agree with Arnold that it may
be going too far (as I was going with the Instruction argument).

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130204/2f3d3854/attachment.html>