Skip to content

Linking: perform macro expansion and type updates just once #2254

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Dec 27, 2021

Conversation

tautschnig
Copy link
Collaborator

@tautschnig tautschnig commented May 29, 2018

This reduces the Linux kernel link time by more than 90% as the previous
approach would repeatedly attempt renamings and replacements across all
hitherto read goto program instructions.

Depends on:

Copy link
Contributor

@smowton smowton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments, looks good. Can you think of any corner cases to test aren't broken, e.g. unifying two units with a weak defn vs. one with a strong defn, or similarly two with incomplete definitions of a struct vs. one that provides the definition? If so are you happy we've already got regression tests taking care of those?

}
goto_modelt goto_model;

goto_model.symbol_table.swap(symbol_table);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely just introduce a <symbol-table, goto-functions> overload -- or perhaps use wrapper_goto_modelt?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, none of wrapper_goto_modelt nor abstract_goto_modelt provide non-const accessors. Is there are good reason those should not be added? (I strictly need non-const access here.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

abstract_goto_modelt should not provide a non-const accessor (as lazy-goto-model must enforce that you only use its proper interface to populate new functions, for example). However wrapper_goto_modelt and goto_modelt may reasonably implement something stronger with non-const accessors.

weak_symbols.insert(symbol_pair.first);
}

linkingt linking(dest.symbol_table,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style (break after open-paren)

std::vector<std::string> binaries, sources;
binaries.reserve(files.size());
sources.reserve(files.size());
std::list<std::string> binaries, sources;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

std::list is quite surprising -- do we really need any of list's properties (cheap insert / delete, stable iterators)? If not I'd stick with vector

Copy link
Collaborator Author

@tautschnig tautschnig May 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer to say "use whatever SequenceContainer you want," but then I can't do that unless I add a template parameter. The difference will not be measurable. The number of entries will typically be a very small number, with the 1000-2000 entries that the Linux kernel yields being close to an upper bound. I have picked std::list, because the number of entries is not known a priori in compilet, and hence append-at-the-end would be inefficient with std::vector. Again, "inefficient" in theory, practically not measurably so.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, not a big deal either way

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not going to insist on using std::list either - but I did have to change one or the other, and if you want me to flip a coin I can do that as well :-)

@tautschnig
Copy link
Collaborator Author

Just a note: it seems I cannot further postpone fixing #1490, which is what the CI failures are.

@tautschnig
Copy link
Collaborator Author

I am now including some commits from #1260.

@tautschnig
Copy link
Collaborator Author

I am working on further fixes in #1260, which should then get merged before this one.

@tautschnig tautschnig requested a review from pkesseli as a code owner January 31, 2019 13:45
@tautschnig tautschnig changed the title Linking: perform macro expansion and type updates just once Linking: perform macro expansion and type updates just once [depends-on: #1260] Feb 1, 2019
@tautschnig tautschnig changed the title Linking: perform macro expansion and type updates just once [depends-on: #1260] Linking: perform macro expansion and type updates just once May 22, 2019
@tautschnig tautschnig assigned kroening and unassigned tautschnig May 22, 2019
@tautschnig tautschnig force-pushed the linear-linking branch 2 times, most recently from e0288d1 to e868217 Compare May 27, 2019 18:24
@tautschnig tautschnig assigned kroening and unassigned tautschnig Jan 29, 2021
@tautschnig tautschnig force-pushed the linear-linking branch 2 times, most recently from 0667ded to 1249602 Compare February 12, 2021 10:14
@tautschnig tautschnig force-pushed the linear-linking branch 4 times, most recently from a7778b0 to 5f4d522 Compare March 17, 2021 00:18
@tautschnig tautschnig force-pushed the linear-linking branch 2 times, most recently from 45fb1b7 to e77cebb Compare May 7, 2021 14:19
@TGWDB
Copy link
Contributor

TGWDB commented Jul 9, 2021

@tautschnig This PR looks like it is close being merged, apart from codeowner review, is there anything outstanding here?

@martin-cs
Copy link
Collaborator

Also paging @chrisr-diffblue and @peterschrammel

Copy link
Contributor

@chrisr-diffblue chrisr-diffblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks like a sensible improvement :-)

@tautschnig
Copy link
Collaborator Author

@tautschnig This PR looks like it is close being merged, apart from codeowner review, is there anything outstanding here?

I had to do a rebase to resolve conflicts, but now it's really just codeowner reviews that are missing.

There is no need to do the additional work that linking on goto
functions entails when the input is just symbol tables. Thus link symbol
tables, and only after linking all of them generate goto functions and
then write the combined goto model.
We do the same work in multiple places, and can optimize the linking process
when knowing about all files to be linked in one step.
This reduces the Linux kernel link time by more than 90% as the previous
approach would repeatedly attempt renamings and replacements across all
hitherto read goto program instructions.
@tautschnig tautschnig merged commit 8c4d15b into diffblue:develop Dec 27, 2021
@tautschnig tautschnig deleted the linear-linking branch December 27, 2021 11:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants