[cpu][fix] Fix onednn_mm crash on consecutive matmuls with same M,K,N and different dtype

[fadara01]

[cpu][fix] Fix onednn_mm crash on consecutive matmuls with same M,K,N and different dtype

Makes weight dtype part of the cache key for ClassMatmulCacheKey to avoid having 2 onednn_mm(s) with same src/weight dimensions and different dtypes mapped to the same dnnl::matmul primitive

Fixes: #27465

Purpose

Fixes: #27465

Test Plan

Reproducer in #27465

Test Result

Reproducer in #27465 passes

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.
• (Optional) Release notes update. If your change is user facing, please update the release notes draft in the Google Doc.

[gemini-code-assist]

Code Review

This pull request correctly addresses a crash in onednn_mm that occurs during consecutive matrix multiplications with identical dimensions but different data types. The fix, which incorporates the weight dtype into the ClassMatmulCacheKey, is sound and properly implemented across the cache key definition, hash function, and equality operator. My review includes two suggestions to further improve the code: one enhances the robustness of the hash function to minimize collisions and maintain performance, and the other improves code clarity by renaming a shadowed variable.

[gemini-code-assist]

Using XOR ^ to combine hash values can lead to a higher rate of collisions, which can degrade the performance of the hash map. A more robust approach is to use a method that mixes the bits more thoroughly, such as a polynomial rolling hash. This is a common practice, for example in Java's hashCode implementation. This principle also applies to the other hash specializations in this file.

Suggested change

	return hash<dnnl_dim_t>()(val.b_n_size) ^ hash<dnnl_dim_t>()(val.b_k_size) ^
	hash<int>()(static_cast<int>(val.b_type));
	return (std::hash<dnnl_dim_t>()(val.b_n_size) * 31 + std::hash<dnnl_dim_t>()(val.b_k_size)) * 31 + std::hash<int>()(static_cast<int>(val.b_type));

[fadara01]

this is something for another PR, let's keep the scope of this PR clear.

[gemini-code-assist]

The local variable key declared at line 497 shadows the function parameter key. This is confusing and error-prone, as it's not immediately obvious which key is being used in subsequent calls (get_matul_class_primitive_cache vs m_size_cache_->get_or_create). It's better to use a more descriptive name for the local cache key to avoid shadowing.

Suggested change

	ClassMatmulCacheKey key = {.b_n_size = b_n_size_, .b_k_size = b_k_size_, .b_type = b_type_};
	m_size_cache_ = get_matul_class_primitive_cache(key, primitive_cache_size_);
	ClassMatmulCacheKey class_key = {.b_n_size = b_n_size_, .b_k_size = b_k_size_, .b_type = b_type_};
	m_size_cache_ = get_matul_class_primitive_cache(class_key, primitive_cache_size_);

[fadara01]

good point

[fadara01]

@bigPYJ1151 this should fix the crash reported in #27465 and #27244

[bigPYJ1151]

Thanks for the fix :)