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.ch...@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.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.
