Skip to content
This repository has been archived by the owner on May 22, 2023. It is now read-only.

[FEAT] Merge IRModules #318

Open
tqchen opened this issue Dec 18, 2022 · 2 comments
Open

[FEAT] Merge IRModules #318

tqchen opened this issue Dec 18, 2022 · 2 comments

Comments

@tqchen
Copy link
Contributor

tqchen commented Dec 18, 2022

Now we finished the first step of global symbol linkage, we are no unblocked to add a feature to merge IRModules. The main thing to address during the merge is name conflict. If both module a and module b have a function with the same name but different semantics, we need to be able to rename them when they are private:

Possible sketchs of actions

  • Add a rename pass that renames functions (optionally rename non-private ones)
    • Take a rename map (GVar=>String or String=>String)
    • Take an bool option to rename_external_funcs (default to false) as we want to avoid doing so unless user really want to do so
    • When rename_external_funcs is false, forcing rename of external func(those with global symbol) causes an error.
  • Scan and find create rename map (GVar=>GVar)
  • Report error when there is conflicting global var that is also external (per structural equality)
  • Run rename pass and merge.
@slyubomirsky
Copy link
Collaborator

We could perhaps allow users to specify some renaming convention so that any name changes would be predictable.

@tqchen
Copy link
Contributor Author

tqchen commented Dec 19, 2022

agree, for private functions, the renaming can happen through adding numbering suffix. By default we should not rename external functions. Because the users only interact with external functions, in theory they should not care about private function renaming but agree having a simple predicatble rule would help

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants