This is the mail archive of the
mailing list for the GCC project.
Re: Fixing inconsistent uses of address costs
- From: Kyrill Tkachov <kyrylo dot tkachov at arm dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>, Sandra Loosemore <sandra at codesourcery dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 30 Mar 2015 16:17:48 +0100
- Subject: Re: Fixing inconsistent uses of address costs
- Authentication-results: sourceware.org; auth=none
- References: <5514286D dot 7080907 at arm dot com> <CAHFci29B+=84ubHRtMw1nSBptE=+ZoyTDmcjJf+_WAfgbMWsnw at mail dot gmail dot com> <5515264C dot 4070404 at arm dot com> <55159406 dot 8020000 at codesourcery dot com> <CAHFci2_91E=48u2Z_Nft-T6G6d1idh6=ZpzeT0LmNQexks_cdg at mail dot gmail dot com>
On 30/03/15 08:14, Bin.Cheng wrote:
On Sat, Mar 28, 2015 at 1:31 AM, Sandra Loosemore
On 03/27/2015 03:43 AM, Kyrill Tkachov wrote:
On 27/03/15 03:29, Bin.Cheng wrote:
As for tree ivopts, address cost is used in both ways. For any
address computation that's invalid, it tries to legitimize it into two
parts, the first part results in alu instructions, the second part
results in address expression of different addressing modes. Right
now the rtx cost (for the first part) and the address cost (for the
second part) are accumulated and compared altogether. I do like the
idea split costs into different types because all elements are
entangled in single cost model, and it's hard to tune for specific
Thanks for explaining.
I think it would be possible to make the comparisons there a bit more
If an address computation is split into alu instructions and a
then carry around the rtx cost of the alu part and the address. When the
comes to compare two computations, we create a more involved way of
For example (would need benchmarking, of course):
* Compare the rtx costs of the alu components and check the address
the legitimate address components using the new hook.
* If the alu part costs are of equal rtx cost, pick the one which has
the preferable legitimate address.
* If expression 'a' has a more expensive alu component than 'b' but a more
preferable address component, then use some tie breaker. Perhaps apply
on the address expression and compare those...
Just as an aside here, tree-ssa-loop-ivopts.c has a lot of other problems
with how it's computing address costs, or it least it did when I last looked
at it a few years ago:
Shortly after I posted that, Qualcomm lost interest in pushing the Hexagon
port upstream or improving performance, so I lost interest in pursuing that
patch when it was evident that it was going to take a lot of work to resolve
the objections. I think fixes for problems (2) and (3) there have since
been pushed by other people, but I'm not sure about the others.
FWIW, I think a big part of the problem here is that the GCC internals
documentation isn't very clear on where the cost of legitimizing an address
(the "alu components" above) should be computed. IIRC when I was last
I aggre that legitimize_address interface matters more than address
cost itself. IVOPT uses it to compute the cost but doesn't use it to
generate final code when rewriting address type uses (though it tries
to mimicry the legitimization behavior and generate lower cost
instructions and addressing expression?).
When you say the legitimize_address interface, do you mean the stuff
from TARGET_LEGITIMIZE_ADDRESS and memory_address_addr_space in explow.c?
Do you think we can just use memory_address_addr_space and estimate the cost
of that in ivopts?
looking at current practice, most targets' implementation of
TARGET_RTX_COSTS didn't make any attempt to account for the address cost in
a MEM -- either adding the cost of legitimizing the address or the cost of
the addressing mode itself (TARGET_ADDRESS_COST). If TARGET_RTX_COSTS is
supposed to do that, its documentation should say so. Or maybe we need a
separate hook like TARGET_LEGITIMIZE_ADDRESS_COST to capture the "alu