The only functional change intended here is contained inside of LocationSize::print: we'll now print LocationSize(N) instead of N to represent location sizes. If the location size is unknown, we'll print LocationSize(unknown) instead of UINT64_MAX (and similar for map tombstone/empty keys). I added the LocationSize prefix because I plan to add precise/unknown markers in D44748.
Ok, I think you missed my point in the other review. The entire idea was to have something which was so obviously correct it didn't need further review. Specifically, to avoid waiting for me or anyone else to review it. Unfortunately, we're now in the worst of both worlds: this change does not appear to be fully NFC and we had a long review delay.
Let me now try to be a bit more specific.
Please declare a *typedef* of uint64_t (not a class) called LocationSize in the MemoryLocation.h header within the llvm namespace. Update all the parameters and fields which are currently uint64_t, but will eventually be a LocationSize. Do not change the meaning of the bit-patterns in any way. Make sure it builds and passes make check, then submit without further review.
Once done, discard this change and rebase your original change over the typedef. This should greatly reduce the LOC changed.
To preserve the old behavior, doesn't this need to be 0?
I recommend leaving this out in the first patch. This part starts changing semantics. Please do the large change *without* changing semantics, then a small patch with the semantic change.
Thanks for the clarification, and sorry about the misunderstanding. I submitted the bit-for-bit NFC patch as r333314, and will rebase the original review soon. :)
If the goal is to preserve bit-for-bit behavior, yes. I failed to mention that I ran tests/built meaningful things with LLVM with assert(isSizeSet()) before all Size accesses, and saw 0 issues. So, I assumed the intent was for size to always be set before anything attempted to access it. Hence, barring a few pathological cases with size nearing UINT64_MAX, the initial value doesn't appear to matter.
I considered this to be more noise than a meaningful functionality change, but I also didn't realize your intent was to have me submit something without review. With that in mind, yes, this change doesn't make much sense in this patch. :)