[PATCH] Increase lto-min-partition

[Wilco Dijkstra]

Prathamesh Kulkarni <prathamesh.kulkarni@linaro.org> wrote:

> Hi Wilco,
> I am working on LTO varpool partitioning to improve performance for
> section anchors.
> I posted a preliminary patch posted at:
> https://gcc.gnu.org/ml/gcc/2016-07/msg00033.html
> Unfortunately I haven't yet been able to benchmark it on ARM yet.
> I am planning to restart working on it again soon.

Thanks, I'll have a look. However I'm not 100% convinced smarter symbol
partitioning is the best way forward. Although it should help, it doesn't take into
account which symbols are currently suitable as anchors (-fcommon
is still the default, and big arrays are not suitable). And you still have to make
difficult choices for symbols that are frequently used across most partitions.

So I believe the best solution is to assign anchors early on so that all partitions
can make use of anchors. Assuming we sort symbols on size and frequency,
it should be feasible to use a single anchor for all simple integer global variables
across the whole application. Assigning early should also allow common
variables to be used in anchors, further increasing the benefit.

Do you think that is feasible?

> Building with a single partition is not scalable. LTO build of
> chromium with x86->arm
> cross with a single partition results in "branch out of range"
> assembler error. I added lto-max-partition
> primarily to work around that limitation.

Yes, GCC doesn't split huge compilation units into multiple text sections
so that the linker can insert long branch veneers. So it's a workaround
for LTO but most RISC targets can still hit the same issue with a single
huge file.

Wilco