Differential D142584
[CodeGen] Add a boolean flag to `Address::getPointer` and `Lvalue::getPointer` that indicates whether the pointer is known not to be null Authored by ahatanak on Jan 25 2023, 2:50 PM.
Details The flag will be used for the arm64e work we plan to upstream in the future (see https://lists.llvm.org/pipermail/llvm-dev/2019-October/136091.html). Passing KnownNonNull_t::True allows clang to avoid emitting null checks on arm64e. Currently the flag has no effect on code generation on other targets. This is the first patch and there are many more places where KnownNonNull_t::True can be passed. I plan to fix those places in future patches.
Diff Detail
Event TimelineComment Actions I'm having a little trouble following what the meaning of an "Address" is with this patch. The Pointer member refers to an encoded value, and calling getPointer() emits IR to decode it? Could use a few comments to explain the API. Comment Actions That's something of a future direction w.r.t this patch, but it's reasonable to talk about it, yeah. Pointer authentication includes the ability to have signed data pointers. Function pointers can only be used opaquely in C, but data pointers are subject to a lot of operations that boil down to pointer arithmetic, both as part of l-value accesses (such as signedPtr->array[i] = 5) and just in abstract pointer-typed expressions (such as &ptr->array[i]). For l-values that are ultimately accessed, we really want to make sure that we do the authentication as close as possible to the actual access rather than authenticating it immediately and then having a raw, attackable pointer sitting around while we set up the access. For pointer expressions in general, if they ultimately need to produce another signed pointer (e.g. we assign into a __ptrauth-qualified l-value), for similar reasons we really want to set up all the arithmetic ahead of time for a secure auth-add-and-resign sequence instead of authenticating and having raw, attackable pointers sitting around as we do the arithmetic. We could do all that with a specialized pointer-with-signature emitter that covers literally every kind of pointer arithmetic, but that requires duplication of a *lot* of code, especially because we have a lot of sanitizers and other special logic also tied to those operations. It seemed much less invasive to add a state to Address where it can be a pair of a signed pointer and an offset, then make a few basic GEP-formation operations accumulate into the offset when the pointer is in that state. Of course, converting an Address into a normal pointer then becomes a non-trivial operation that needs a CGF. Pointer authentication doesn't sign null pointers, so we have to do some explicit extra checks as part of this when the pointer is possibly null, and this patch is trying to make that easier to avoid.
Comment Actions Add a bit to Address and LValue that tracks whether the pointer is known not to be null. Comment Actions There are more places where we know contextually the pointer can't be null and can set the bit to KnownNonNull or set the bit of an LValue or Address using an existing Address's KnownNonNull bit.
Comment Actions The approach here makes sense.
Comment Actions Address review comments.
Comment Actions
Comment Actions LGTM
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||