search for: x86typeconversioncosttblentry

...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>

...;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...

On Jan 10, 2013, at 2:19 PM, Renato Golin Linaro <renato.golin at linaro.org> wrote: > I'm also thinking about the individual instructions cost (getArithmeticInstrCost, getShuffleCost, etc). That can be a simple and easily parallelized task. I got the A9 manual that has the cost of all instructions (including NEON and VFP), that should give us a head start. Renato, Thanks for

On 9 January 2013 17:10, Nadav Rotem <nrotem at apple.com> wrote: > For example: > "opt -cost-model -analyze dumper.ll -mtriple=thumbv7 > -mcpu=cortex-a15" > > I also run the vectorizer with -debug-only=loop-vectorize because it dumps > the costs of all of the instructions with different vectorization factors, > and it also detects the different kinds