Skip to content
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

Improve Namer #120

Closed
doug-q opened this issue Oct 10, 2024 · 1 comment
Closed

Improve Namer #120

doug-q opened this issue Oct 10, 2024 · 1 comment

Comments

@doug-q
Copy link
Collaborator

doug-q commented Oct 10, 2024

We have emit::namer::Namer which controls what LLVM symbols are assigned to hugr functions. It is configured with a "prefix" and a bool controlling whether node ids are appended to symbols.
When the prefix is "hugr." and the bool is true, then a hugr function "main" with a node index 3, will lower to a symbol like "hugr.main.3".

This allows users to ensure that all hugr functions lower to a symbol starting with "hugr.", and that all hugr functions have unique, deterministic symbols. If the user ensures everything else (e.g. the functions and globals referenced in their lowerings) in the module has a different unique prefix, then they will never have any symbol clashes.

All "symbol computation logic" should go through an expanded and improved Namer, which is configured with a prefix tree of "namespaces", where every leaf has a unique prefix.

At present ConstExternalSymbol lowers directly to a reference to the symbol specified. This is annoying if you want to control what symbols a program is allowed to reference, one should be able to configure the Namer to prefix "hugr.external." to the symbol name, and the lowering for ConstExternalSymbol should delegate to the Namer.

We will soon (#52) be generating LLVM functions (i.e. destructors) which are not lowered hugr functions. The Namer should have a leaf in its prefix tree e.g. "hugr.destructors." which is prefixed to any destructor name. We also will need to figure out how to name the symbol from the type, and we may need internal mutablity and an incrementing "symbol id" to generate unique names. We need to pay attention to determinism, but I don't think we have to give it up.

Note that if destructors are going into "hugr.destructors.", then hugr functions should go into e.g. "hugr.user.", i.e they can't go into "hugr." because that is a prefix of "hugr.destructors.".

@hugrbot
Copy link
Collaborator

hugrbot commented Nov 25, 2024

Migrated to hugr repo

@hugrbot hugrbot closed this as completed Nov 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants