[PATCH] D65242: [ELF] More dynamic relocation packing

Peter Collingbourne via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Jul 29 14:44:47 PDT 2019


pcc added a comment.

In D65242#1605242 <https://reviews.llvm.org/D65242#1605242>, @victoryang wrote:

> In D65242#1605239 <https://reviews.llvm.org/D65242#1605239>, @pcc wrote:
>
> > In D65242#1605129 <https://reviews.llvm.org/D65242#1605129>, @victoryang wrote:
> >
> > > In D65242#1604903 <https://reviews.llvm.org/D65242#1604903>, @pcc wrote:
> > >
> > > > In D65242#1604869 <https://reviews.llvm.org/D65242#1604869>, @victoryang wrote:
> > > >
> > > > > In D65242#1604825 <https://reviews.llvm.org/D65242#1604825>, @pcc wrote:
> > > > >
> > > > > > > Linking libmonochrome in Chromium for
> > > > > > >  Android, targeting ARM32, I see a .rel.dyn of size 127697 bytes, as
> > > > > > >  compared to 150532 bytes without this change.
> > > > > >
> > > > > > IIRC over 99% of relocations in libmonochrome were relative, so I didn't implement anything for the non-relative relocations, but maybe there are more non-relative relocations now. I can imagine that if say you were building it as a component build that would result in more non-relative relocations than in shipping builds. It may also be more compelling to mention how much this helps for the Android platform which I believe uses non-relative relocations more heavily.
> > > > >
> > > > >
> > > > > Thanks for pointing this out! I've updated the description to include test results on Android.
> > > >
> > > >
> > > > Thanks for adding those figures. I'm still not sure about your Chromium figures though. I just did a quick build myself and I'm still seeing >99% relative relocations without significant duplication in the non-relative relocations so I'm curious to see what your `args.gn` looks like for Chromium.
> > >
> > >
> > > My args.gn is:
> > >
> > >   target_os = "android"
> > >   use_goma = true
> > >
> > >
> > > Also FWIW I'm building a debug build.
> >
> >
> > Okay, since that's a component build and not realistic as a size measurement for anything that's shipped I probably wouldn't mention the Chromium numbers in the commit message since they're somewhat misleading.
>
>
> Fair enough. I removed the part about Chromium. Just for my own education, what's the right way of testing this for Chromium? Is it just that I should do a Release build than a Debug build?


For a basic release build (which is a rough approximation of what's shipped) this is what I use:

  is_component_build = false
  is_debug = false
  target_cpu = "arm64"
  target_os = "android"
  use_goma = true

That lets you build an ARM32 binary with `ninja android_clang_arm/libmonochrome.so` and an ARM64 binary with `ninja libmonochrome.so`. You can also add `is_official_build = true` to get something significantly closer to what's shipped.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65242/new/

https://reviews.llvm.org/D65242





More information about the llvm-commits mailing list