<div dir="ltr">On 29 January 2013 19:20, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">+1 for smaller tests.</div></blockquote><div><br></div><div style>My initial assumption is that we could have a concrete case, so that we could add the costs as we implement them. But I agree, I'll use your example below and tweak the types to make sure we're getting the correct casts.</div>
<div style><br></div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>In the case of func0 we pay for sign-extension while in func1 it can be merged into the arithmetic. The question is now which cost should we return: the optimistic or the pessimistic one? I would lean towards the optimistic one (as you do) but I think we should get an agreement on which one to use in such cases.</div>
</div></div></blockquote><div><br></div><div style>This is something I want to address in the very near future: take into account a stream of instructions, not just the types involved. We discussed about this, and I think we should first get the costs tables out, even if slightly inaccurate  and fix issues as we can. Similar arguments apply for multiply+accumulate, insertelement/extractelement tuples, instruction combine, etc.</div>
<div style><br></div><div style>Another issue is pipeline stalls. Ignoring the hard bits (barriers, cache state, etc), we know for sure that on A9, changing from ARM to NEON is free, but changing back is not. We also know that changing between VFP and NEON is even worse. LLVM generates code based on the assumption that these are free, and create very bad code.</div>
<div style><br></div><div style>However, I agree that we should first get our assumptions in line, as long as we're being consistent. It may not be perfect, but we should deal with such differences as time comes. I don't mind if we go pessimistic or optimistic, because we'll have to address it sooner rather than later anyway.</div>
<div style><br></div><div style>I'll submit a new patch once I have a decent test.<br></div><div style><br></div><div style>Thanks!</div><div style>--renato</div></div></div></div>