[PATCH] D26130: [ELF] - Implemented --symbol-ordering-file option.

[Rafael Espíndola via llvm-commits]

I got curious to try another case in clang. I timed compiling
X86MCTargetDesc.ii to an object file.  The page faults go from just
56,988 to 56,946 since most faults are not in the binary.

The interesting thing is that the running time goes from 4.403053515
to to 4.178112244. The speedup seems to be because of better cache
locality:

before:

230,347,955 L1-icache-load-misses ( +- 0.26% )
 3,899,458 iTLB-load-misses # 25.19% of all iTLB cache hits ( +- 0.05% )
 15,478,050 iTLB-loads ( +- 0.03% )

after:

218,043,304 L1-icache-load-misses ( +- 0.07% )
 2,934,008 iTLB-load-misses # 24.70% of all iTLB cache hits ( +- 0.22% )
 11,880,350 iTLB-loads ( +- 0.19% )

This is just a lucky coincidence that the script produced something
that was also useful for cache locality, but I think this shows that
an heuristic designed to improve cache locality (like
svn://gcc.gnu.org/svn/gcc/branches/google/gcc-4_9/function_reordering_plugin/)
can make use of --symbol-ordering-file.

Cheers,
Rafael

On 1 November 2016 at 10:22, George Rimar <grimar at accesssoftek.com> wrote:
>>> That was the place where I stuck today - was unable to get symbol file for firefox,
>>> as it does not have static build and script produced empty symbol file always.
>>>
>>> Looking on the updated script seems you use shared clang build ?
>>
>>No, I was using a static one, but I just checked that the script works
>>on a shared one too. The impact is smaller as we cannot control the
>>libc initialization. It goes from 423 to 323 page faults.
>>
>>Cheers,
>>Rafael
>
> Ah, I said incorrectlly. It was not empty, but symbols it produces belonged to
> firefox binary and not DSO. So list of libxul symbols would be empty.
> And it seemed unreasonable to test in such conditions when all logic is in libxul.so.
>
> I did not try shared clang.
>
> George.