On Mon, Nov 4, 2013 at 7:38 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng <bin.ch...@arm.com> wrote:
>> Hi,
>>
>> The IVOPT in GCC has a problem that it does not use cost of auto-increment
>> address expression in accounting, while it retreats to cost of address
>> expression if auto-increment addressing mode is unavailable.
>> For example, on ARM target:
>> 1) the cost of "[reg]" (which is 6) is used for address expression "[reg],
>> #off";
>> 2) the cost of "[reg+off]" (which is 2) is used for address expression
>> "[reg, #off]!";
>>
>> This causes:
>> 1) cost of non-auto increment address expression is used for auto-increment
>> address expression;
>> 2) different address costs are used for pre/post increment address
>> expressions.
>> This patch fixes the problem by computing, caching and using the cost of
>> auto-increment address expressions.
>>
>> Bootstrap and test on x86/arm. Is it OK?
>
> But don't you need to adjust
>
> static bool
> determine_use_iv_cost_address (struct ivopts_data *data,
> struct iv_use *use, struct iv_cand *cand)
> {
> bitmap depends_on;
> bool can_autoinc;
> int inv_expr_id = -1;
> comp_cost cost = get_computation_cost (data, use, cand, true, &depends_on,
> &can_autoinc, &inv_expr_id);
>
> if (cand->ainc_use == use)
> {
> if (can_autoinc)
> cost.cost -= cand->cost_step;
>
> this which seems to try to compensate for your issue?
That's where problem gets complicated depending on how backend defines
address cost. For back ends define cost according to the true cost of
addressing mode approximately, the address cost of auto-increment
addressing mode doesn't take the saved stepping instruction into
consideration, so the code is necessary.
Moreover, according to gcc internal's description about
TARGET_ADDRESS_COST, RISC machines may define different address cost
for addressing modes which actually have equal execution on
micro-architecture level (like ARM for now). The problems are:
1) Though address costs are defined in this "discriminated" way, it's
unlikely to have the saved stepping instruction considered either.
The address cost of auto-increment address expression shouldn't go so
far.
2) We think the "discriminated" address cost model is established
before gimple pass and is outdated. The true micro-architecture
address cost (or cost normalized with COSTS_N_INSNS) should be used in
GCC nowadays. The rtl passes like fwprop_addr which use address cost
as heuristic information should be refined... but that's totally
another problem (am investigating it).
So overall, I think the stepping cost should to be subtracted here.
>
> Or maybe I don't understand.
>
> CCing Bernd who implemented this IIRC.
Any suggestions appreciated.
Thanks.
bin
--
Best Regards.
