[PATCH] D77330: Consider increasing the default ARM32 page size to 64k.

[Stephen Hines via Phabricator via llvm-commits]

srhines added a subscriber: rprichard.
srhines added a comment.

So it turns out that the ld shipped in the NDK actually did have the 64KB max-page-size patch, so not taking this patch would change current user behavior. Thanks to @MaskRay for sharing the exact binutils patch we were looking for to verify that it has it. For that reason, this patch should be fine for our 32-bit ARM NDK users. For the platform, we'll see if we should just set the max-page-size back to 4KB explicitly in the build rules, but that shouldn't affect this CL.

In D77330#1960004 <https://reviews.llvm.org/D77330#1960004>, @jyknight wrote:

> In D77330#1959071 <https://reviews.llvm.org/D77330#1959071>, @srhines wrote:
>
> > We (Android Google folks) have an internal thread going on about what implications this might have, but I can say that I am concerned about making this kind of change for ARM Android targets. Even though we manually set a 4KB max page size in our platform builds for 32-bit, we also have to consider the needs of NDK developers (i.e. those folks making native applications/games/etc.). Some of their build configurations might behave very differently with this change, so my current thinking is that 64KB should **not** be the default for ARM Android targets.
>
>
> Can you say more about your concern? I was actually thinking the exact opposite -- that the special-case in the Driver to use 4K pages on Android AArch64 could very likely be removed, now that using the default 64k max-page-size will no longer cause the binary size to increase.


Android is currently using `-z separate-code` for AArch64. Upping the default max page size will bloat the binaries even more (it costs us ~17MB alone on our platform image for `-z separate-code` with the 4KB max-page-size - Google-folk can look at http://b/150506341 for more details on the tradeoffs here). Thanks to @rprichard  for pointing out recent changes here so that I hopefully can avoid regressing other size/performance behaviors unintentionally. For removing the special case in Clang, I'll go ahead and hard-code the 4KB max-page-size in aosp, so our behavior won't change with a future toolchain update. That will allow me to remove the driver hack safely. Thanks everyone for the good suggestions here, and for helping simplify things while not causing any unintended side effects.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77330