On 10 January 2013 23:00, Nadav Rotem <nrotem at apple.com> wrote:> Some of the costs for the arithmetic operations should be handled > automatically by the BasicTTI (which asks TartetLowering if the type and > operations are legal). We need to have cost tables for things like "trunk > <4 x i64> to <4 x i8>" because even TLI does not know how custom operations > gets lowered. >BasicTTI::getCastInstrCost() assumes that they're free, which is probably so that it returns something that doesn't break the cost model. I can see the X86 table in X86TTI::getCastInstrCost(), are you expecting something similar? I shall investigate all possible combinations and try to build a similar model. That also means we should re-using the X86TypeConversionCostTblEntry as a more generic structure? cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/cf0ae139/attachment.html>
On Jan 11, 2013, at 7:36 AM, Renato Golin Linaro <renato.golin at linaro.org> wrote:> On 10 January 2013 23:00, Nadav Rotem <nrotem at apple.com> wrote: > Some of the costs for the arithmetic operations should be handled automatically by the BasicTTI (which asks TartetLowering if the type and operations are legal). We need to have cost tables for things like "trunk <4 x i64> to <4 x i8>" because even TLI does not know how custom operations gets lowered. > > BasicTTI::getCastInstrCost() assumes that they're free, which is probably so that it returns something that doesn't break the cost model. > > I can see the X86 table in X86TTI::getCastInstrCost(), are you expecting something similar? I shall investigate all possible combinations and try to build a similar model. >Yes. I am expecting something similar.> That also means we should re-using the X86TypeConversionCostTblEntry as a more generic structure?Yes, it would be nice to generalize it. Maybe we can even unify the two-operand and one-operand tables into a single structure. Thanks, Nadav -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/f1af8c4a/attachment.html>
On 11 January 2013 17:06, Nadav Rotem <nrotem at apple.com> wrote:> Yes. I am expecting something similar. > > That also means we should re-using the X86TypeConversionCostTblEntry as > a more generic structure? > Yes, it would be nice to generalize it. Maybe we can even unify the > two-operand and one-operand tables into a single structure. >Great, I'll have a look! --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/106fcb34/attachment.html>