This is the mail archive of the gcc-patches@gcc.gnu.org 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: [RFC] introduce --param max-lto-partition for having an upper bound on partition size


On April 1, 2016 3:48:35 PM GMT+02:00, Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> wrote:
>Hi,
>The attached patch introduces param max-lto-partition which creates an
>upper
>bound for partition size.
>
>My primary motivation for this patch is to fix building chromium for
>arm
>with -flto-partition=one.
>Chromium fails to build with -flto-partition={none, one} with assembler
>error:
>"branch out of range error"
>because in both these cases LTO creates a single text section of 18 mb
>which exceeds thumb's limit of 16 mb and arm backend emits a short
>call if caller and callee are in same section.
>This is binutils PR18625:
>https://sourceware.org/bugzilla/show_bug.cgi?id=18625
>With patch, chromium builds for -flto-partition=one (by creating more
>than one but minimal number of partitions to honor 16 mb limit).
>I haven't tested with -flto-partition=none but I suppose the build
>will still fail for none, because it won't involve partitioning?  I am
>not sure how to fix for none case.
>
>As suggested by Jim in binutils PR18625, the proper fix would be to
>implement branch relaxation in arm's port of gas, however I suppose
>only LTO will realistically create such large sections,
>and implementing branch relaxation appears to be quite complicated and
>probably too much of
>an effort for this single use case, so this patch serves as a
>work-around to the issue.
>I am looking into fine-tuning the param value for ARM backend to
>roughly match limit
>of 16 mb.
>
>AFAIU, this would change semantics of --param n_lto_partitions (or
>-flto-partition=one) from
>"exactly n_lto_partitions" to "at-least n_lto_partitions". If that's
>not desirable maybe we could add
>another param/option ?
>Cross-tested on arm*-*-*.
>Would this patch be OK for stage-1 (after getting param value right
>for ARM target) ?

What do you want to achieve?  Changing =one semantics doesn't look right to me.
Adding a param for maximum size sounds good in general, but only to increase the maximum number of partitions for =balanced (the default).

Richard.

>
>Thanks,
>Prathamesh



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