Ping^2 Thanks, bin
On Tue, Nov 12, 2013 at 3:08 PM, bin.cheng <bin.ch...@arm.com> wrote: > Ping in this one. > Hi Bernd, could you please help us on this one? > 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. > > > > -- Best Regards.
