This is an archive of the discontinued LLVM Phabricator instance.

[BOLT] Fix jump table issue for split functions
ClosedPublic

Authored by maksfb on Jul 21 2023, 7:33 PM.

Details

Summary

A jump table in a split function may contain an entry matching a start
address of another fragment of the function. While converting addresses
to labels, we used to ignore such entries resulting in underpopulated
jump table. Change that, so we always create one label per address.

Diff Detail

Event Timeline

maksfb created this revision.Jul 21 2023, 7:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2023, 7:33 PM
maksfb requested review of this revision.Jul 21 2023, 7:33 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2023, 7:33 PM
Amir accepted this revision.EditedJul 21 2023, 9:24 PM

Thanks. I hope it won't break our jump table detection in unexpected ways.
As a suggestion to minimize fallout – we can restrict this new treatment to fragment starts only (ie. to *.cold functions only)

This revision is now accepted and ready to land.Jul 21 2023, 9:24 PM
maksfb updated this revision to Diff 543289.Jul 23 2023, 8:30 AM
maksfb retitled this revision from [BOLT] Fix jump table issue for fragmented functions to [BOLT] Fix jump table issue for split functions.
maksfb edited the summary of this revision. (Show Details)

Update comment.

Thanks. I hope it won't break our jump table detection in unexpected ways.
As a suggestion to minimize fallout – we can restrict this new treatment to fragment starts only (ie. to *.cold functions only)

In postProcessJumpTables() we are not making decisions on what entries belong to the table. The population of the table is happening in BinaryContext.
The code that I'm changing is supposed to convert addresses to labels, but was skipping the corner case.

This revision was automatically updated to reflect the committed changes.