This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fixes to estimate_num_insns from pretty-ipa branch
2009/4/13 Jan Hubicka <hubicka@ucw.cz>:
>> On Fri, Apr 10, 2009 at 1:51 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> > Hi,
>> > also haydn finished testing today. ?Patch is pretty much SPEC neutral.
>> > There are overall code size savings for -Os and for C++ benchmarks.
>> > There are however also two important regressions in performance:
>> > tramp3d http://gcc.opensuse.org/c++bench-haydn/tramp3d/
>> > and some of botan benchmarks
>> > http://gcc.opensuse.org/c++bench-haydn/botan/
>> >
>> > The problem is that inliner accounts now loads and stores and on tramp3d
>> > a lot of loads+stores are optimized away only post-inlining. ?On
>> > pretty-ipa this problem is solved within inliner heuristics by preticate
>> > function deciding whether given statement is probably going to be
>> > optimized. ?This predicate results true for all reads/writes of objects
>> > pointed to by pointers passed to function (this objects) and all
>> > reads/writes of of non-gimple-temporary function parameters. ?This
>> > "guesses" that after inlining they will be SRAed away.
>> >
>> > Pretty-ipa has more than this in inliner heursitics. ?In particular it
>> > kills completelly inline metrics in estumate_num_insns and computes
>> > "benefits" based on how much function execution time is supposed to
>> > improve by inlining compared to how much program will grow.
>> >
>> > I don't want to track this all in single mega patch. ?So I would suggest
>> >
>> > 1) Merge the code size changes and mark the two tests as xfail.
>> > There don't seem to be any performance regressions related to these
>> > problems, we really just change compette unrolling decisions in way
>> > testsuite does not expect.
>>
>> I am not really comfortable in XFAILing testcases this way. ?At least you
>> need to make sure to file regression bugzillas and assign them to you.
>
> That is fine with me...
> Those are really bit strange side cases: we expect complette unrollig
> for size to happen even if it increases code size because we know that
> it will be optimized better then.
Well, that's obviously a good test for the heuristics then ;)
Richard.
> Honza
>