Skip to content

Conversation

copybara-service[bot]
Copy link

@copybara-service copybara-service bot commented Sep 25, 2025

NodeMap<V>: an interned Map<Node*, V> implementation.

This is a std::map-alike for specifically maps with Node* as keys which holds the mapped value logically interned into the node itself. This is substantially faster than a flat-hash-map in many cases with speedups of up to 10% seen in optimization time on some targets when integrated into a few passes.

This implementation is specifically made so that it can (mostly) function as a drop in replacement for flat_hash_map<Node*, V>. There are some notable differences however:

  1. All operations perform a pointer read on the key argument. This means calling practically any function with an invalid Node* is UB.
  2. reserve(...) is not available (since it does nothing)
  3. iteration order is defined as the most-to-least-recently added.
  4. Each node with any data associated with it on any map has a vector with up to {max number of live maps} pointers associated with it. This extra space is never cleaned up on the assumption that only a relatively small number of maps will ever be simultaneously live.
  5. Once a node has been deleted from a function/package/etc all data associated with it on any map is deallocated. The node will not be visible in any way in the map (ie size will go down by 1) and it will be UB to try to read anything about that key.
  6. All keys used in a NodeMap must be from the same package.
  7. NodeMap has pointer, reference and iterator stability (adding/removing new values to the map does not change the pointer to the value or invalidate any iterators or references except those pointing to the exact entry removed).

Any read of the map requires 4 pointer reads (node -> user-data-vector -> map node -> value).

This map is (very slightly) less efficient than flat_hash_map if the value type is trivially copyable. To ensure that this is respected by default the map will have a compile error if you attempt to use it with these sorts of values.

@copybara-service copybara-service bot force-pushed the test_811020776 branch 3 times, most recently from 77928e9 to 6574d52 Compare September 26, 2025 16:38
This is a std::map-alike for specifically maps with Node* as keys which holds the mapped value logically interned into the node itself. This is substantially faster than a flat-hash-map in many cases with speedups of up to 10% seen in optimization time on some targets when integrated into a few passes.

This implementation is specifically made so that it can (mostly) function as a drop in replacement for flat_hash_map<Node*, V>. There are some notable differences however:

1) All operations perform a pointer read on the key argument. This means calling practically any function with an invalid Node* is UB.
2) reserve(...) is not available (since it does nothing)
3) iteration order is defined as the most-to-least-recently added.
4) Each node with any data associated with it on any map has a vector with up to {max number of live maps} pointers associated with it. This extra space is never cleaned up on the assumption that only a relatively small number of maps will ever be simultaneously live.
5) Once a node has been deleted from a function/package/etc all data associated with it on any map is deallocated. The node will not be visible in any way in the map (ie size will go down by 1) and it will be UB to try to read anything about that key.
6) All keys used in a NodeMap must be from the same package.
7) NodeMap has pointer, reference and iterator stability (adding/removing new values to the map does not change the pointer to the value or invalidate any iterators or references except those pointing to the exact entry removed).

Any read of the map requires 4 pointer reads (node -> user-data-vector -> map node -> value).

This map is (very slightly) less efficient than flat_hash_map if the value type is trivially copyable. To ensure that this is respected by default the map will have a compile error if you attempt to use it with these sorts of values.

PiperOrigin-RevId: 811020776
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

Successfully merging this pull request may close these issues.

1 participant