This is an archive of the discontinued LLVM Phabricator instance.

[lld][RISCV] Handle relaxation reductions of more than 65536 bytes
ClosedPublic

Authored by mcgrathr on May 16 2023, 1:57 PM.

Details

Summary

In a real-world case with functions that have many, many
R_RISCV_CALL_PLT relocations due to asan and ubsan
instrumentation, all these can be relaxed by an instruction and
the net result is more than 65536 bytes of reduction in the
output .text section that totals about 1.2MiB in final size.

This changes InputSection to use a 32-bit field for bytesDropped.
The RISCV relaxation keeps track in a 64-bit field and detects
32-bit overflow as it previously detected 16-bit overflow. It
doesn't seem likely that 32-bit overflow will arise, but it's not
inconceivable and it's cheap enough to detect it.

This unfortunately increases the size of InputSection on 64-bit
hosts by a word, but that seems hard to avoid.

Diff Detail

Event Timeline

mcgrathr created this revision.May 16 2023, 1:57 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 16 2023, 1:57 PM
mcgrathr requested review of this revision.May 16 2023, 1:57 PM

Current code models are such that you can’t have more than 2 GiB of code, so 32-bit seems fine I think?

MaskRay accepted this revision.May 16 2023, 2:28 PM

IIRC @luismarques mentions that with LTO we may see a bytesDropped overflow. OK, I don't object to the idea that we pay some memory overhead to make this work.

Current code models are such that you can’t have more than 2 GiB of code, so 32-bit seems fine I think?

The fatal("section size decrease is too large: " + Twine(delta)); is definitely useless for regular code. uint64_t delta = 0; may catch some people's linker stress tests...

This revision is now accepted and ready to land.May 16 2023, 2:28 PM
This revision was landed with ongoing or failed builds.May 16 2023, 3:00 PM
This revision was automatically updated to reflect the committed changes.