[PATCH] D142584: [CodeGen] Add a boolean flag to `Address::getPointer` and `Lvalue::getPointer` that indicates whether the pointer is known not to be null

John McCall via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jan 26 14:18:37 PST 2023


rjmccall added inline comments.


================
Comment at: clang/lib/CodeGen/Address.h:97
+  llvm::Value *
+  getPointer(KnownNonNull_t KnownNonNull = KnownNonNull_t::False) const {
     assert(isValid());
----------------
ahatanak wrote:
> rjmccall wrote:
> > Apologies if this rehashes a conversation we had earlier, but does it make more sense to track this internally in `Address`?  Some `Address` sources definitely known that they're non-null, and the places where we only know that *contextually* could definitely just pass it down to e.g. `EmitPointerWithAlignment`.  That would make it a less invasive change for all the clients of `getPointer()`.
> Yes, tracking it in `Address` and `LValue` is another way to fix the problem. The implementation in my local branch currently adds an `IsKnownNonNull` flag to the constructor of `Address` and method `setKnownNonNull` to both `Address` and `LValue`. The method is called when the pointer is known not to be null contextually.
Okay.  It might make sense to pass this into `EmitPointerWithAlignment` contextually instead of just relying on changing it afterwards, since it's possible that some of the work there can be optimized when the pointer is contextually not allowed to be null.  (For example, C++ derived-to-base conversions, although I think we might optimize those already by using a different `CastKind` when there's a contextual requirement to be non-null (e.g. when it's the `this` argument of a method call).  But I'm sure there are situations that doesn't kick in that would be optimized, like if you `static_cast` the pointer before calling a method on it.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142584/new/

https://reviews.llvm.org/D142584



More information about the cfe-commits mailing list