Another thing that could impact the orderfile here is that -finstrument-function-entry-bare happens before outlining, so you won't see calls to __cyg_profile_func_enter_bare coming from outlined functions.

I think we can entirely mitigate this issue by adding OUTLINED_FUNCTION* to the orderfile. According to:
https://storage.googleapis.com/chrome-supersize/viewer.html?load_url=milestones%2Farm_64%2FMonochrome.apk%2Freport_72.0.3626.7.ndjson&include=outlined+function

The size of all outlined functions is <50kb. we should just make sure outlined functions get grouped together.

lizeb - wdyt? want to take this on?

I can do this.

lld doesn't do wildcards, but the less than 1k outlined functions according to that supersize pull so we can just list them explicitly.

Some additional data: pulling from the build 73.0.3666.0_arm_64_Monochrome, it looks like outlined functions are about 1M total in size. There are only about 1300 different symbol names, but due to ICF (and maybe other stuff?) there is a lot of repetition and aliasing going on.

More stats: most outlined methods are 16 bytes long; the largest is 292; there are 67k distinct offsets pointed to by an OUTLINED_FUNCTION_* symbol.

An arbitrary sample of what outlined functions look like for those whoa re interseted:

00000000007ac220 <OUTLINED_FUNCTION_418>:
  7ac220:	aa1403e0 	mov	x0, x20
  7ac224:	aa1503e1 	mov	x1, x21
  7ac228:	1446a3e1 	b	19551ac <_ZN3WTF6VectorIiLj0ENS_18PartitionAllocatorEE14AppendSlowCaseIRKiEEvOT_>

00000000007ac22c <OUTLINED_FUNCTION_419>:
  7ac22c:	9100e3e8 	add	x8, sp, #0x38
  7ac230:	910183e0 	add	x0, sp, #0x60
  7ac234:	14966c71 	b	2d473f8 <_ZN5blink19ToPositionInDOMTreeERKNS_16PositionTemplateINS_16EditingAlgorithmINS_13NodeTraversalEEEEE>

00000000007ac238 <OUTLINED_FUNCTION_420>:
  7ac238:	aa1303f4 	mov	x20, x19
  7ac23c:	f8408e88 	ldr	x8, [x20,#8]!
  7ac240:	d65f03c0 	ret

00000000007ac244 <OUTLINED_FUNCTION_421>:
  7ac244:	b9400808 	ldr	w8, [x0,#8]
  7ac248:	aa0303f3 	mov	x19, x3
  7ac24c:	aa0003f4 	mov	x20, x0
  7ac250:	6b01011f 	cmp	w8, w1
  7ac254:	d65f03c0 	ret

how much does outlining save us on aarch64?

When lld with outlining landed, it saved ~2.5mb

Was looking at bug 923936, and realized that other linker-generated symbols exist, and might likewise hurt orderfile. Maybe need to the same logic for them?

.L.ref.tmp.##

https://storage.googleapis.com/chrome-supersize/viewer.html?load_url=milestones%2Farm%2FMonochrome.apk%2Freport_72.0.3626.7.ndjson&include=%5C.L&exclude=assets%2Funwind_cfi&type=tdrR

Makes up only 23kb, but if they are spread out could be suboptimal.

Actually, since .L symbols are created by the linker (as opposed to outlined symbols), it might be the case that they are positioned intelligently to start with.

One risk is that if our orderfile lists these symbols, and we are not using an exactly up-to-date orderfile, that we would be mis-ordering them due to name changes.

E.g. they are named .L.ref.tmp.1, .L.ref.tmp.2, ...

If we define their ordering, and then a code change happens that causes all the numbers to shift, our defined ordering will be actively hurting the layout.

Interesting, I'm not finding these L.ref.tmp symbols in libmonochrome when doing official 64 or 32 bit builds, neither with objdump nor nm.

How are you finding them?

Interesting that they don't appear in nm. Maybe they are not "real" symbols. They are listed in the linker map file.