This is the mail archive of the 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: Fixes to estimate_num_insns from pretty-ipa branch

2009/4/13 Jan Hubicka <>:
>> On Fri, Apr 10, 2009 at 1:51 PM, Jan Hubicka <> 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
>> > and some of botan benchmarks
>> >
>> >
>> > 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 ;)


> Honza

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