This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Ping^2

Thanks,
bin

On Tue, Nov 12, 2013 at 3:08 PM, bin.cheng <bin.cheng@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.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.
>
>
>
>



-- 
Best Regards.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]