You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The value of a null pointer is not always `0`. For example, on AMDGPU, the null
pointer in address spaces 3 and 5 is `0xffffffff`. Currently, there is no
target-independent way to get this information, making it difficult and
error-prone to handle null pointers in target-agnostic code.
We do have `ConstantPointerNull`, but it might be a little confusing and
misleading. It represents a pointer with an all-zero value rather than
necessarily a real `nullptr`.
This PR introduces the concept of a *sentinel pointer value* to `DataLayout`,
representing the actual `nullptr` value for a given address space. The changes
include:
- A new interface function:
```
APInt getSentinelPointerValue(unsigned AS)
```
This function returns an `APInt` representing the sentinel pointer value for
the given address space `AS`. An `APInt` is used instead of a literal integer
to support cases where pointers are wider than 64 bits (e.g., AMDGPU’s address
space 8).
- An extension to the data layout string format:
```
p[n]:<size>:<abi>[:<pref>[:<idx>[:<sentinel>]]]
```
The new `<sentinel>` component specifies the sentinel value for the
corresponding pointer. It currently supports two values:
- `0` for an all-zero value
- `f` for a full-bit set value
These two values are the most common representations of `nullptr`. It is
unlikely that any target would define `nullptr` as a random value.
A follow-up patch series will introduce an equivalent of `ConstantPointerNull`
that represents the actual `nullptr`, built on top of this PR.
0 commit comments