- User Since
- Nov 2 2015, 8:43 AM (211 w, 3 d)
Mar 8 2016
Sorry for the late entry... Some of my questions could have been already answered.
Feb 23 2016
Guys, can you please take a quick look...?
Feb 17 2016
Jan 28 2016
Jan 27 2016
Can this be landed now...?
Jan 26 2016
Make sure all kind of alisees are handled + test.
Implement Peters comments.
Thanks Mehdi. I will let some time for Peter to comment if he pleases...
Jan 22 2016
Jan 20 2016
Cleared addrspace in tests.
Implemented suggested changes.
Jan 19 2016
Jan 18 2016
Jan 15 2016
Implemented Peter's suggestions.
Excellent suggestions. New patch will be up shortly.
Got it. Thanks...
Sorry - I told you I am starting cold :)
Sorry to come in cold on the discussion, but let me ask a naive question - Why can't we teach CloneModule to drop unnecessary metadata in the same way we use a selector function for GlobalVariables (ShouldCloneDefinition) - why copy it in the first place?
Jan 14 2016
This would be even better if EquivalenceClasses would guarantee deterministic order... but anyhow - this should reflect Peter's comments.
Add to the split module utility an SCC based method which allows not to globalize any local variables.
Jan 13 2016
Here is one issue with EquivalenceClasses. It uses
> Constant merging sometimes introduces additional dependencies that
might be counterproductive for splitting, and we are currently looking at our
options to address that.
How bad is the problem? I think that as long as your re-globalization is
conservatively correct (i.e. does not pollute the global namespace) it would
still be a useful contribution.
Jan 12 2016
In the end it depends on what your linker does. If your linker tracks global symbols, turning locals into globals will not play well even with hidden attribute.
I think Tobias beat me to the answer - at the least we can have linker errors if we try to blindly globalize locals with identical names. Renaming them will not always work either, since our customers might rely on presence of specific symbols in the final image... There are also other reasons for that, but correctness of at least some corner cases seems like a hard justification on its own :-)
You are right in general - we have seen this bias. To address the issue, we re-globalize things that were internalized for LTO leaving only _real_ dependencies. If that step is interesting for anyone - we can definitely upstream it... but it will not go all the way. Constant merging sometimes introduces additional dependencies that might be counterproductive for splitting, and we are currently looking at our options to address that.
Jan 11 2016
Yes, We had this discussion with Chris (see more context here)
Not really. See the test case - even if we mix GV with and without sections they will all be processed.