From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Biener <rguenther@suse.de>
Cc: Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org>,
gcc Patches <gcc-patches@gcc.gnu.org>,
Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
Jan Hubicka <hubicka@ucw.cz>
Subject: Re: [RFC] introduce --param max-lto-partition for having an upper bound on partition size
Date: Mon, 04 Apr 2016 12:00:00 -0000 [thread overview]
Message-ID: <20160404120030.GD14122@kam.mff.cuni.cz> (raw)
In-Reply-To: <alpine.LSU.2.11.1604041342040.13384@t29.fhfr.qr>
> > Um not sure if I understood correctly.
> > Do we want to constrain individual partition size by adding parameter
> > lto-max-partition
> > for balanced partitioning but not for -flto-partition=one
> > case (since latter would also change semantics of =one) ?
>
> Yes, I think so.
Yep, I agree. Having partition one that produces multiple partitions doesn't seem to make much sense.
Given that we have such not so predictable target specific limits on size of single translation unit
we can handle, I suppose adding a resonable limit to the default balanced partitioning makes more sense.
One can always push the behaviour you intend by setting max partitions to 1 (I suppose max size should
have precedence over max partitions)
Honza
>
> Richard.
>
> > Thanks,
> > Prathamesh
> > >
> > > Richard.
> > >
> > > --
> > > Richard Biener <rguenther@suse.de>
> > > SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
> >
> >
>
> --
> Richard Biener <rguenther@suse.de>
> SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
next prev parent reply other threads:[~2016-04-04 12:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 13:48 Prathamesh Kulkarni
2016-04-01 17:33 ` Richard Biener
2016-04-04 7:47 ` Prathamesh Kulkarni
2016-04-04 8:26 ` Richard Biener
2016-04-04 11:19 ` Prathamesh Kulkarni
2016-04-04 11:42 ` Richard Biener
2016-04-04 12:00 ` Jan Hubicka [this message]
2016-04-04 13:28 ` Prathamesh Kulkarni
2016-04-04 14:14 ` Jan Hubicka
2016-04-05 11:11 ` Prathamesh Kulkarni
2016-04-05 11:28 ` Richard Biener
2016-04-05 12:55 ` Prathamesh Kulkarni
2016-04-05 12:58 ` Richard Biener
2016-04-06 7:47 ` Prathamesh Kulkarni
2016-04-06 8:14 ` Richard Biener
2016-04-06 8:53 ` Prathamesh Kulkarni
2016-04-06 9:07 ` Richard Biener
2016-04-06 9:24 ` Richard Biener
2016-04-25 11:58 ` Prathamesh Kulkarni
2016-04-26 11:01 ` Richard Biener
2016-04-26 20:45 ` Prathamesh Kulkarni
2016-04-27 7:28 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160404120030.GD14122@kam.mff.cuni.cz \
--to=hubicka@ucw.cz \
--cc=gcc-patches@gcc.gnu.org \
--cc=prathamesh.kulkarni@linaro.org \
--cc=ramana.radhakrishnan@arm.com \
--cc=rguenther@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).