My general inclination is to go with the “easier” variant, that is to change the semantics of existing constructs rather than renaming them. At least when looking at the final outcome, we’re not really gaining anything by doing renames like nonnull → nonnullptr, but introducing a good bit of churn. Especially as the new semantics are only relevant with a new (not yet used) data layout, code can be migrated incrementally.
ConstantPointerNull has ~260 mentions in llvm/, but from a quick survey only a small number of them will require adjustment to more strongly distinguish zero vs null.
What I am more concerned about in terms of migration is various other APIs like Constant::isNullValue() and Constant::getNullValue(). These should probably be split into Constant::isZeroValue() and Constant::isNullPtrValue(), as these are no longer the same.
However, a problem here is that the isZeroValue() query requires DataLayout to determine whether a null pointer has value zero or not, and getting DL into all the necessary places can be a pain. Though probably a lot of the uses are only actually working on integers.
It is upgraded during bitcode reading: llvm-project/llvm/lib/Bitcode/Reader/BitcodeReader.cpp at fd800487382e2ee3944493d58a961b6f48290243 · llvm/llvm-project · GitHub
As this is a common attribute, it is also upgraded during IR parsing (this is generally not required): llvm-project/llvm/lib/AsmParser/LLParser.cpp at fd800487382e2ee3944493d58a961b6f48290243 · llvm/llvm-project · GitHub
Probably worth noting that “allow specifying that zero is the null pointer in a non-default address space” and “allow specifying that there is a null pointer other than zero” do not necessarily have to be done at the same time. The former is a lot simpler than the latter.