<div dir="ltr">On 4 February 2013 20:44, Arnold Schwaighofer <span dir="ltr"><<a href="mailto:aschwaighofer@apple.com" target="_blank">aschwaighofer@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>Would a tree of <opcode, return-type, input-type>s work? How deep would it need to be?<br>

<br>
</div>Agreed, if we decide on more information than just type and opcode we will need some abstract representation.<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div>What I was thinking was something flat and target-independent, like:</div><div><br></div><div>enum VectFlags {</div><div style>  ConstantShift = 0x0000001;</div><div style>  VariableShift = 0x0000002;</div>
<div style>  ...</div><div style>  ArithmeticCast = 0x0000100;</div><div style>  MemoryCast = 0x0000200;</div><div style>  ...</div><div>};</div>
<div><br></div><div style>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).</div><div style><br></div><div style>
getCastInstructionCost(opcode, dstTy, srcTy, Flags) {</div><div style><br></div><div style> isArith = Flags & ArithmeticCost;</div><div style><br></div><div style>  costtable = {</div><div>    { ISD::SEXT, MVT::Foo, MVT::Bar1, isArith+1 }</div>
<div style>    { ISD::SEXT, MVT::Foo, MVT::Bar2, isArith }</div><div>    { ISD::SEXT, MVT::Foo, MVT::Bar3, 1 }</div><div>    { ISD::SEXT, MVT::Foo, MVT::Bar4, 0 }</div><div style>    ...</div><div style>  }</div><div style>
<br></div><div style>}</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>> 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.<br>
</div></blockquote><div><br></div><div style>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).</div><div style><br></div><div style>
cheers,</div><div style>--renato</div></div></div></div>