-
Notifications
You must be signed in to change notification settings - Fork 273
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
Conversation
There was a problem hiding this 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?
src/goto-cc/compile.cpp
Outdated
} | ||
goto_modelt goto_model; | ||
|
||
goto_model.symbol_table.swap(symbol_table); |
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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, |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 :-)
Just a note: it seems I cannot further postpone fixing #1490, which is what the CI failures are. |
865e875
to
2a21bb5
Compare
2a21bb5
to
e28b874
Compare
I am now including some commits from #1260. |
I am working on further fixes in #1260, which should then get merged before this one. |
e28b874
to
92be095
Compare
92be095
to
7eedf66
Compare
7eedf66
to
f1671af
Compare
e0288d1
to
e868217
Compare
0635c92
to
4ea5de8
Compare
4ea5de8
to
21a9ef9
Compare
21a9ef9
to
2ac5414
Compare
0667ded
to
1249602
Compare
a7778b0
to
5f4d522
Compare
45fb1b7
to
e77cebb
Compare
@tautschnig This PR looks like it is close being merged, apart from codeowner review, is there anything outstanding here? |
Also paging @chrisr-diffblue and @peterschrammel |
There was a problem hiding this 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 :-)
e77cebb
to
353b12d
Compare
I had to do a rebase to resolve conflicts, but now it's really just codeowner reviews that are missing. |
353b12d
to
4995057
Compare
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.
4995057
to
ee42ac6
Compare
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: