)]}'
{
  "commit": "bfc075d6114bc9289dcba1c06a062f8f072109a0",
  "tree": "e0d6d6cafe5b10d704f66b1eb078893643264d30",
  "parents": [
    "c2f9f643d1bd2af101bcc0b3705439c10f9d5f33"
  ],
  "author": {
    "name": "Evan Brown CA",
    "email": "ezb@google.com",
    "time": "Thu Oct 22 12:28:59 2026 -0700"
  },
  "committer": {
    "name": "Copybara-Service",
    "email": "copybara-worker@google.com",
    "time": "Mon Oct 26 12:24:34 2026 -0700"
  },
  "message": "Compute `hash_of(key)` before `common().capacity()` in `find_large` and `find_or_prepare_insert_large`.\n\nWhen `hash_of(key)` involves a conditional or non-inlined function call (such as string hashing calling `CombineLargeContiguousImplOn64BitLengthGt32` for strings `\u003e 32B` or custom hash functors), evaluating `common().capacity()` before `hash_of(key)` forces the compiler to keep the computed capacity live across the call, spilling into callee-saved registers or stack slots. For inlined scalar hashes (`int64_t`), computing `common().capacity()` (`shlxq`/`bzhiq`) before `hash_of(key)` also delays starting the `crc32q` hash dependency chain by 1 cycle.\n\nComputing `hash_of(key)` before `common().capacity()` avoids keeping `capacity()` live across `hash_of(key)` and starts the `hash_of(key)` dependency chain immediately on table lookup entry.\n\nPiperOrigin-RevId: 1004969102\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "ba34be9d705ca6fb47b344fdf04948c7210b229f",
      "old_mode": 33188,
      "old_path": "absl/container/internal/raw_hash_set.h",
      "new_id": "ce8a1e4332c49be113e45c16acad4b7d340ad388",
      "new_mode": 33188,
      "new_path": "absl/container/internal/raw_hash_set.h"
    }
  ]
}