[PATCH] PR middle-end/38509: add -Wfree-nonheap-object warning option

This patch adds an option for enabling/disabling the warning for attempting to free nonheap objects (PR/38509). The warning is imprecise and can issue false positives. Bootstrapped on x86-64. Ok for trunk? Mark 2011-08-11 Mark Heffernan PR middle-end/38509 * common.opt

Re: [PATCH] PR middle-end/38509: add -Wfree-nonheap-object warning option

Ping? Mark On Fri, Aug 12, 2011 at 9:41 AM, Mark Heffernan wrote: > This patch adds an option for enabling/disabling the warning for > attempting to free nonheap objects (PR/38509).  The warning is > imprecise and can issue false positives. > > Bootstrapped on x86-64.  Ok for

[google] With FDO/LIPO inline some cold callsites

% geomean performance on x86-64 (depending on microarch) on internal benchmarks with < 1% average code size increase. Bootstrapped and reg tested. Ok for google/gcc-4_6? Mark 2011-08-23 Mark Heffernan * basic-block.h (maybe_hot_frequency_p): Add prototype. * cgrap

[google] Increase hotness count fraction

hot. The performance improvement is likely due to increased inlining (more callsites are considered hot and available for inlining). Bootstrapped and reg-tested on x86-64. OK for google/gcc-4_6? Mark 2011-08-24 Mark Heffernan * params.def (hot-bb-count-fraction): Change default value

Re: [google] Increase hotness count fraction

On Thu, Aug 25, 2011 at 6:49 AM, Ramana Radhakrishnan wrote: > I know this is intended for the google branches but shouldn't such a > change be in the x86_64 backend rather than such a general change to > params.def . I wouldn't consider this a backend-specific change. The parameter generally af

[google] Pessimistic stack frame accounting during inlining

k frames much larger than the parameterized limits. Internal benchmarks show minor performance differences with non-fdo and lipo, but overall neutral.  Tested/bootstrapped on x86-64. Ok for google-main? Mark 2011-06-07  Mark Heffernan           * cgraph.h (cgraph_global_info): Remove field.  

Re: [google] pessimize stack accounting during inlining

g the inliner from pushing the frame size much beyond the imposed limit especially if the limit is large (eg, many K) relative to the typical total size of spill slots, arguments, etc. Mark > > Richard. > > > Thanks, > > > > David > > > > On Tue, Jun 7, 2011 at

[google] Increase inlining limits with FDO/LIPO

benchmarks by about geomean 1.5% to 3% with LIPO (depending on microarch), and 1% to 1.5% with FDO. Size increase is negligible (0.1% mean). Bootstrapped and regression tested on x86-64. Trunk testing to follow. Ok for google/main? Mark 2011-05-17 Mark Heffernan * opts.c (finish_options

Re: [google] Increase inlining limits with FDO/LIPO

ere these parameters are set to someplace more appropriate (to where the flags are set when profile gen/use is indicated). Verified identical binaries are generated. OK as updated? Mark 2011-05-18 Mark Heffernan * opts.c (set_profile_parameters): New function. Inde

Re: [google] Increase inlining limits with FDO/LIPO

rc_flag and flag_branch_probabilities. Mark > > David > > > On Wed, May 18, 2011 at 10:39 AM, Mark Heffernan wrote: >> On Tue, May 17, 2011 at 11:34 PM, Xinliang David Li >> wrote: >>> >>> To make consistent inline decisions between profile-gen

Re: [google] Increase inlining limits with FDO/LIPO

Verified identical binaries created and submitted. Mark On Wed, May 18, 2011 at 11:37 AM, Xinliang David Li wrote: > Ok with that change to google/main with some retesting. > > David > > On Wed, May 18, 2011 at 11:34 AM, Mark Heffernan wrote: >> On Wed, May 18, 2011 at 10: