Page MenuHomePhabricator

Encode address offsets of basic blocks relative to the end of the previous basic blocks.
AcceptedPublic

Authored by rahmanl on Jul 20 2021, 10:23 PM.

Details

Summary

Conceptually, the new encoding emits the offsets and sizes as label differences between each two consecutive basic block begin and end label. When decoding, the offsets must be aggregated along with basic block sizes to calculate the final relative-to-function offsets of basic blocks.

This encoding uses smaller values compared to the existing one (offsets relative to function symbol).
Smaller values tend to occupy fewer bytes in ULEB128 encoding. As a result, we get about 25% reduction
in the size of the bb-address-map section (reduction from about 9MB to 7MB).

Diff Detail

Event Timeline

rahmanl created this revision.Jul 20 2021, 10:23 PM
rahmanl requested review of this revision.Jul 20 2021, 10:23 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 20 2021, 10:23 PM
rahmanl edited the summary of this revision. (Show Details)Jul 20 2021, 10:34 PM
jhenderson accepted this revision.Jul 26 2021, 1:21 AM

Seesm reasonable to me, but I don't know the codegen code well enough to be 100% confident in that aspect - might be best to try to get a second opinion.

This revision is now accepted and ready to land.Jul 26 2021, 1:21 AM
tmsriram accepted this revision.Jul 26 2021, 10:02 AM

LGTM

llvm/tools/llvm-readobj/ELFDumper.cpp
6849

Just making sure, is it possible that there could be some padding between basic blocks which might not get accounted for in size calculations? I guess this is being done after the assembler has done its work so it should be fine?

Thanks for the review @tmsriram and @jhenderson.

llvm/tools/llvm-readobj/ELFDumper.cpp
6849

Yes. The padding you are mentioning is BBE.Offset. This is the offset from the end of a block to the beginning of the next. So it will be accounted for as well (at line 6759).