Sorry for the late entry... Some of my questions could have been already answered.

Guys, can you please take a quick look...?

Updated test.

Can this be landed now...?

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...

Cleared addrspace in tests.

Implemented suggested changes.

Hi Rafael,

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?

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.

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.

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.

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.