[PATCH GCC]Compute, cache and use cost of auto-increment rtx patterns in IVOPT

[bin.cheng]

Ping in this one.
Hi Bernd, could you please help us on this one?
Please ignore the previous ping message because I used the wrong email
account.

Sorry for the inconvenience.

Thanks,
bin

> -----Original Message-----
> From: Bin.Cheng [mailto:amker.cheng@gmail.com]
> Sent: Monday, November 04, 2013 8:56 PM
> To: Richard Biener
> Cc: Bin Cheng; Bernd Schmidt; GCC Patches
> Subject: Re: [PATCH GCC]Compute, cache and use cost of auto-increment rtx
> patterns in IVOPT
> 
> On Mon, Nov 4, 2013 at 7:38 PM, Richard Biener
> <richard.guenther@gmail.com> wrote:
> > On Mon, Nov 4, 2013 at 4:31 AM, bin.cheng <bin.cheng@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.