In `LibraryCallKit::inline_unsafe_access()`, we encountered an issue where speculative types, hidden behind `CheckCastPP` nodes, prevented the correct classification of null pointers. While we resolved this specific case by using `base->uncast()` in `LibraryCallKit::classify_unsafe_addr()`, there may be additional cases where speculative types interfere with exact comparisons against preallocated type constants.

Exact pointer comparisons involving speculative types can yield incorrect results, especially when comparing against constants like `TypePtr::BOTTOM`, `TypePtr::NOTNULL`, and others.

For example, a comparison such as:
```cpp
TypePtr::NOTNULL == ptr
```
may fail if `ptr` contains speculative information (propagated through nodes like `CheckCastPP`), leading to incorrect behavior or even the generation of dead code. This issue is not limited to `LibraryCallKit::classify_unsafe_addr()` but could impact multiple areas in the codebase where preallocated types are compared against speculative types using pointer equality.

A common scenario would be a base pointer carrying speculative type information, which may not match `TypePtr::NULL_PTR`, even if the pointer represents a null value.

**Suggested Fix**:  
Review all uses of preallocated type constants (e.g., `TypePtr::BOTTOM`, `TypePtr::NOTNULL`, etc.) and ensure that comparisons with speculative types are handled correctly. Introducing `uncast()` or similar speculative stripping mechanisms where necessary can help mitigate these issues and prevent the generation of incorrect or dead code.