Prathamesh Kulkarni <prathamesh.kulka...@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
