[PATCH] D53975: Start adding the supporting code to perform out-of-process allocator enumeration.

[Dan Liew via Phabricator via llvm-commits]

delcypher added a comment.

In https://reviews.llvm.org/D53975#1296826, @delcypher wrote:

> In https://reviews.llvm.org/D53975#1296359, @kcc wrote:
>
> > I'm puzzled. 
> >  Why would you make AddressSpaceView non-zero-sized given that Load is a static member function?
>
>
> Sorry. I was thinking of the old implementation and not the new implementation (I shouldn't reply when I'm really tired). Yes, you're right all implementations of `AddressSpaceView` will be zero-sized.


Okay I just checked. Unfortunately your idea to have an instance of `AddressSpaceView` as a member and add `operator()` isn't going to work. It seems C++ does not allow zero sized classes. Even a class with zero members have to be at least 1 byte in size apparently.
This implies that adding `AddressSpaceView` as a member could change the data layout which is a deal breaker for us. So for now we'll have to do without the syntactic sugar for now. I'll upload a new patch soon.

Just in case you were curious here's an example that shows empty classes don't have zero size.

  #include <stdio.h>
  #include <stdint.h>
  #include <inttypes.h>
  
  using uptr = uintptr_t;
  
  struct LocalAddressSpaceView {
    template <typename T>
    static T *Load(T *target_address, uptr num_elements = 1) {
      return target_address;
    }
  
    LocalAddressSpaceView() {
      static_assert(sizeof(LocalAddressSpaceView) == 1, "Must be zero sized");
    }
  };
  
  struct Foo {
    LocalAddressSpaceView a;
    LocalAddressSpaceView b;
  };
  
  int main() {
    Foo foo;
    printf("Foo: 0x%" PRIx64 "\n", reinterpret_cast<uintptr_t>(&foo));
    // Note &(foo.a) != &(foo.b);
    printf("Foo.a: 0x%" PRIx64 "\n", reinterpret_cast<uintptr_t>(&(foo.a)));
    printf("Foo.b: 0x%" PRIx64 "\n", reinterpret_cast<uintptr_t>(&(foo.b)));
    return 0;
  }


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D53975