This frees up one slot in the HandleBaseKind enum, which I will use
later to add a new kind of value handle. The size of the
HandleBaseKind enum is important because we store a HandleBaseKind in
the low two bits of a (in the worst case) 4 byte aligned pointer.
Details
Diff Detail
- Build Status
Buildable 6019 Build 6019: arc lint + arc unit
Event Timeline
FYI unless advised otherwise, I plan to land
https://reviews.llvm.org/D32270
https://reviews.llvm.org/D32268
https://reviews.llvm.org/D32267
https://reviews.llvm.org/D32266
without a re-review once this patch lands.
include/llvm/IR/ValueHandle.h | ||
---|---|---|
285–286 | I think we should allow assigning over the TrackingVH as well, much like we would with a moved-from object. With this change... | |
290 | ... we can remove the 'null-is-allowed' aspect of the entire class. Specifically the CheckValidity call can go awoy from setValPtr and instead is only needed for getValPtr. I don't think this really reduces the utility of the handle in any way and it makes it much simpler IMO. | |
308 | And I think this should go back to checking ValueHandleBase::isValid which handles things like trying to extract the value pointer from a densemap key. |
Address review.
After this TrackingVH is a simple wrapper on WeakVH with two extra checks on access.
LGTM, this looks like a nice simplification and frees up the useful bit to support non-tracking VHs. Tiny nit below, but feel free to submit this and the non-tracking weak stuff when you're ready.
include/llvm/IR/ValueHandle.h | ||
---|---|---|
314 | stray space before the '. |
I think we should allow assigning over the TrackingVH as well, much like we would with a moved-from object.
With this change...