No, Google branch is not yet synced to 4.9 head.
David
On Sun, Oct 19, 2014 at 1:11 PM, Jan Hubicka wrote:
>> It was in upstream 4.9 branch, but got reverted in r215061 to fix
>> PR/61214 and PR/62224.
>
> Was your tests done with this change or without?
>
> Honza
> It was in upstream 4.9 branch, but got reverted in r215061 to fix
> PR/61214 and PR/62224.
Was your tests done with this change or without?
Honza
It was in upstream 4.9 branch, but got reverted in r215061 to fix
PR/61214 and PR/62224.
David
On Sun, Oct 19, 2014 at 1:21 AM, Jan Hubicka wrote:
>> Hi Honza,
>>
>> As David says, we will do some more experiments with the change you
>> suggest and speculative devirtualization, but we needed to
> > In opts.c I have:
> > case OPT_fprofile_use:
> > if (!opts_set->x_flag_branch_probabilities)
> > ...
> > /* Indirect call profiling should do all useful transformations
> > speculative devirtualization does. */
> > if (!opts_set->x_flag_devirtualize_speculatively
On Sun, Oct 19, 2014 at 1:19 AM, Jan Hubicka wrote:
>> >
>> > I am surprised you hit the size limits with 4.9 only - for quite some time
>> > we keep all virtual functions in callgarph until inlining. In fact 4.9 is
>> > first
>> > that works harder to drop them early (because I hit the problem w
> Hi Honza,
>
> As David says, we will do some more experiments with the change you
> suggest and speculative devirtualization, but we needed to make this
> change in part to get an internal release out. One of the issues was a
> recent change to cp/decl2.c to make virtual function decls needed
>
> >
> > I am surprised you hit the size limits with 4.9 only - for quite some time
> > we keep all virtual functions in callgarph until inlining. In fact 4.9 is
> > first
> > that works harder to drop them early (because I hit the problem with LTO
> > where they artifically bloat the size of LTO o
On Sat, Oct 18, 2014 at 4:22 PM, Jan Hubicka wrote:
>>
>> The virtual functions will be emitted in some modules, right? If they
>> are hot, they will be included with the auxiliary modules. Note that
>> LIPO indirect call profile will point to the comdat copy that is
>> picked by the linker in the
Hi Honza,
As David says, we will do some more experiments with the change you
suggest and speculative devirtualization, but we needed to make this
change in part to get an internal release out. One of the issues was a
recent change to cp/decl2.c to make virtual function decls needed
under flag_dev
>
> The virtual functions will be emitted in some modules, right? If they
> are hot, they will be included with the auxiliary modules. Note that
> LIPO indirect call profile will point to the comdat copy that is
> picked by the linker in the instrumentation build, so it guarantees to
> exist.
If
On Sat, Oct 18, 2014 at 3:23 PM, Jan Hubicka wrote:
>> Devirtualization needs more tuning to be usable internally. We have
>> seen 1.6% size increase on average, but unnoticable performance
>
> Does that happen with -fno-devirtualize-speculatively?
>
Not sure -- I will do some experiment.
>> imp
> Devirtualization needs more tuning to be usable internally. We have
> seen 1.6% size increase on average, but unnoticable performance
Does that happen with -fno-devirtualize-speculatively?
> improvement with this option on. I would rather use the size budget to
> make inliner more aggressive :)
Devirtualization needs more tuning to be usable internally. We have
seen 1.6% size increase on average, but unnoticable performance
improvement with this option on. I would rather use the size budget to
make inliner more aggressive :)
For instrumentation build, some of our builds will reach the bu
ok.
David
On Sat, Oct 18, 2014 at 9:25 AM, Teresa Johnson wrote:
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
>
> Patch attached. Passes internal te
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
OK, with profile instrumentation (that you seem to try to minimize) i can see
how you get noticeably more
> Disabling devirtualization reduces code size, both for instrumentation
> (because
> many more virtual functions are kept longer and therefore instrumented) and
> for
> normal optimization.
Can you refer bit more on the problem? Full devirtualization should not
increase code size, speculative d
Disabling devirtualization reduces code size, both for instrumentation (because
many more virtual functions are kept longer and therefore instrumented) and for
normal optimization.
Patch attached. Passes internal testing and regression tests. Ok for google/4_9?
Thanks,
Teresa
--
Teresa Johnson
17 matches
Mail list logo
