This is an archive of the discontinued LLVM Phabricator instance.

[lld/ELF] Add flag to print relocation stats
Changes PlannedPublic

Authored by aeubanks on Aug 17 2023, 9:02 AM.

Details

Summary

This is useful for measuring relocation pressure across builds.

For now, print the min/max 32-bit signed offset across relocations.

Diff Detail

Event Timeline

aeubanks created this revision.Aug 17 2023, 9:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2023, 9:02 AM
aeubanks requested review of this revision.Aug 17 2023, 9:02 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 17 2023, 9:02 AM

This adds overhead to most relocations. The maximum offset doesn't necessarily reflect the pressure. We need to look at the distribution.
I am therefore object to such an approach.
As an alternative, we can relink with --emit-relocs and use another program to analyze the relocations.

This adds overhead to most relocations. The maximum offset doesn't necessarily reflect the pressure. We need to look at the distribution.
I am therefore object to such an approach.
As an alternative, we can relink with --emit-relocs and use another program to analyze the relocations.

I measured this (probably should have gotten numbers before sending this out) and yeah this does noticeably increase link times even when it's turned off so this current approach won't work.

But for continual monitoring of relocation pressure across binaries in a large build system, it's quite convenient to do this in the linker rather than as a separate step. Are you against all approaches of doing this in lld during the link (under a flag that won't impact link times at all), or just approaches in lld that affect lld link times?

This adds overhead to most relocations. The maximum offset doesn't necessarily reflect the pressure. We need to look at the distribution.
I am therefore object to such an approach.
As an alternative, we can relink with --emit-relocs and use another program to analyze the relocations.

I measured this (probably should have gotten numbers before sending this out) and yeah this does noticeably increase link times even when it's turned off so this current approach won't work.

But for continual monitoring of relocation pressure across binaries in a large build system, it's quite convenient to do this in the linker rather than as a separate step. Are you against all approaches of doing this in lld during the link (under a flag that won't impact link times at all), or just approaches in lld that affect lld link times?

I am concerned with any changes that affect the performance. Some really high-profile features can outweigh the cost, e.g. relocation overflow checking (the code your patch is changing), RISC-V linker relaxation.
For relocation monitoring, let me just be clearer. I think doing it in lld is almost always unacceptable. This is a data analysis task that should be done by another program.
Just use --emit-relocs.

MaskRay added a comment.EditedAug 17 2023, 11:15 AM

I am generally concerned with any changes touching relocation scanning (including this and D142880). Last time I checked, lld's relocation scanning takes 2x time of mold's.

mold sections don't use struct Relocations. mold uses template class for all ports.

It's possible we should change our relocation scanning to be more mold like in the future.

aeubanks planned changes to this revision.Aug 17 2023, 12:52 PM

while being able to measure relocation pressure across all binaries in our build system is nice, I'll look into monitoring specific binaries with a separate build that uses --emit-relocs and your relocation scanning binary that you wrote