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, PR 51600] IPA-CP workaround for negative size cloning estimates


2011/12/22 Jan Hubicka <hubicka@ucw.cz>:
>> On Wed, Dec 21, 2011 at 5:29 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> >> Hi,
>> >>
>> >> given that we already have a workaround for zero size increase
>> >> estimates from estimate_ipcp_clone_size_and_time, I see little reason
>> >> not to extend it to negative values too, 0 is really just as bad as -2
>> >> that we are getting in the testcase. ?Hopefully this will allow peple
>> >> who hit this bug proceed with their testing.
>> >>
>> >> Bootstrapped and tested on x86-64-linux with no regressions.
>> >> OK for trunk?
>> >
>> > Hmm, so the size value is not negative because estimate_ipcp_clone_size_and_time
>> > would return 0 or negative value but because of
>> > ?size -= stats.n_calls * removable_params_cost
>> > (i.e. the callee function is so small that the program will really shrink because
>> > of reduced call overhead)?
>>
>> That doesn't make sense - is the 'removable_params_cost' maybe not
>> in-line with what estimate_num_insns computes for the param part
>> of the call cost?
>
> n_calls is the number of calls of the clonned function, not number of calls
> within the clonned function. ?When you have function that is called 1000 times
> and is very small, clonning it and removing one of its arguments makes your
> program shrink.

But why throw program shrink amount and function size together - that
does not make sense (at least if you expect only positive final function size).

> At least that is my understanding of the code here. Martin?
>
> Honza


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