[cfe-dev] [RFC] Solution for preserving the address space of ‘this’ in C++ methods

[JF Bastien via cfe-dev]

Hi Anastasia,

I find this terrifying. Using const method qualifiers correctly already leads to silly code repetition. I’d like to entirely remove volatile qualified methods from C++ (see wg21.link/p1152 <http://wg21.link/p1152>). Your proposal adds an unbounded number of qualifiers, and the code duplication this entails seems nonsensical.

Do you foresee user code ever changing meaningfully based on address space?
Or is this just a trick to get different codegen around `this`?

I suspect you’re trying to achieve the later. If so, qualifiers on methods just don’t seem like the right language-level solution.

Address spaces on variables seem totally sane, and I agree that you want encapsulation, and somehow tracking address space on `this` makes sense. So I’m not saying I disagree with your goal. I’m saying method qualifiers seem like a terrible fit.

I think we need a completely different language solution which allows the same C++ code to codegen differently based on variable address space.

JF


> On Dec 6, 2018, at 3:41 AM, Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> Hello,
> 
> 
> I
>  am trying to sort out the use of address spaces in C++ classes in Clang, and I would like to get your feedback about the following problem.
> 
> 
> Every
>  C++ method implicitly contains a pointer to an object that invokes the method (aka ‘this’). It is implicitly added by Clang during parsing of a class. On architectures that use address spaces, objects might be instantiated in different address spaces. For
>  example, in OpenCL we may wish to construct objects in a specific address space, e.g. __local, that is shared between a group of threads; there is no syntax in core C++ that allows specifying the address space of ‘this’ and, therefore, the compiler can’t provide
>  an implementation that preserves the address space of an object.
> 
> I
>  would like to implement an extension that would allow specifying address space qualifier on methods to signal that the method is to be used with objects constructed in that address space.
> 
> Here
>  is an example:
> 
> 
> 1
>  struct C {
> 2
>    void foo() __attribute__((address_space(1)));
> 3
>    void foo();
> 4
>  };
> 
> If
>  an instance ‘obj’ of struct ‘C’ is allocated in address space ‘1’ a call to ‘obj.foo()’ will resolve to the method on line 2; if ‘obj’ is not allocated in a specific address space then the implementation on line 3 will be used. In essence this is overloading
>  based on the address space qualifiers of a method.
> 
> For
>  languages with explicit address space semantics, like OpenCL, it would look like:
> struct
>  C {
>    void
>  foo() __local;
>    void
>  foo();
>  };
> 
> This
>  approach has one problem, however, if the implementation of a method does not differ for different address spaces, i.e. the qualification is only done to preserve the address space of ‘this’, multiple copies of the same method will have to be defined. Example:
> 
>  struct
>  C {
>    int
>  a;
>    int
>  geta() __attribute__((address_space(1))) {return a;}
>    int
>  geta() {return a;}
>  };
> 
> A
>  better solution, suggested by John McCall [2], that can extend the template syntax for methods with an address space of ‘this’ would require a larger language change and would require longer time before it would become available to users of Clang.
> 
> The
>  current plan is as follows:
> 
> Implement
>  the aforementioned language extension to allow the overloading of methods qualified with an address space. A prototype implementation of this is available in [1]. If there are no objections here I am happy to work on the patch for this. I am quite confident
>  it can be progressed quickly considering that the general overloading mechanism with method qualifiers is already in place. Let me know if I might have missed something though.
> 
> 
> Work
>  towards a longer term solution, potentially utilizing templates to reduce code repetition and make address spaces in C++ a more usable feature. I would appreciate some assistance either with ideas on language design or with prototyping/drafting the language
>  spec proposal.
> 
> 
> 
> Feedback
>  request:
> 
> Please
>  let me know if there are any objections to implementing option 1 and if you have any details to be considered.
> 
> 
> Please
>  let me know if you are interested in being involved with the language design for option 2. I would particularly be interested to get some people from the general C++ community that use address spaces, or not!, as currently my main background is mainly in GPU/OpenCL
>  area.
> 
> 
> [1]
> https://github.com/KhronosGroup/SPIR/commit/0cfb6f7533d42ae3398a8574efd8abbdac88ac44 <https://github.com/KhronosGroup/SPIR/commit/0cfb6f7533d42ae3398a8574efd8abbdac88ac44>
> 
> [2]
> https://reviews.llvm.org/D54862#1308125 <https://reviews.llvm.org/D54862#1308125>
> 
> Thanks
>  in advance,
> Anastasia
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181206/15433ce2/attachment.html>