[PATCH 2/3] ARM cost model: Address computation in vector mem ops not free
Renato Golin
renato.golin at linaro.org
Thu Feb 7 11:32:26 PST 2013
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>
More information about the llvm-commits
mailing list