ARM Cast Cost Table

[Renato Golin]

Updated:

http://llvm-reviews.chandlerc.com/D345




On 29 January 2013 19:48, Renato Golin <renato.golin at linaro.org> wrote:

> 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/021e9ab7/attachment.html>