ARM Cast Cost Table

[Renato Golin]

On 29 January 2013 19:20, Arnold Schwaighofer <aschwaighofer at apple.com>wrote:

> +1 for smaller tests.
>

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.


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

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.

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.

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.

I'll submit a new patch once I have a decent test.

Thanks!
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130129/bad3341d/attachment.html>