[PATCH 2/3] ARM cost model: Address computation in vector mem ops not free

[Renato Golin]

On 7 February 2013 14:31, Arnold <aschwaighofer at apple.com> wrote:

> I agree with you, it is unfortunate. However, I am trying to model an
> idiosyncrasy of the processor that has a big implication on performance. It
> is very expensive on swift if you happen to load into a S register, or D
> sub lane. Two such instructions are not pipelined but sequentialized.
>

In that case, the cost will be much more than 2 or 3, no?


Stride has the value of the isConsecutivePtr method:
>

Ok, in the original code you had:

if (Stride < 0)
  return parent::cost();
return Cost;

In this you have:

if (Stride > 0)
  return Cost;
return parent::cost();

It seems you're missing the case where it's == 0, but I can't tell which
way it should go.


I don't think we need a function call for the value 3 here. It is a value
> just like any other that is returned by TTI.
>

What I'm trying to say is that this value seems to come out of the blue. I
could be wrong, obviously, but it seems to me that you're experimenting
with a micro-benchmark and fine-tuning to your particular example, which is
dangerous on a wider perspective.

I understand that this might be a big hit on a set of examples, but we
should get some constants out, just to make it clear that we're not talking
about "idealized cycle count", but something else entirely.

Like:

const int AVOID_AT_ALL_COSTS = 100;
const int DANGEROUS_IN_MOST_CASES = 10;
const int NOT_GOOD_BUT_COULD_BE_OK = 5;

etc...

cheers,
--renato

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130207/112461b1/attachment.html>