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

[Richard Smith via cfe-dev]

I think the code duplication at the object code level is unavoidable -- we
need to generate different code for the different overloads here. To solve
the problem of a duplication at the source level, I think we should wait
for http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0847r1.html
rather than inventing our own thing.

On Thu, 6 Dec 2018, 09:42 JF Bastien via cfe-dev <cfe-dev at lists.llvm.org
wrote:

> 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). 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:
>
>
>    1. 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.
>
>
>
>    1. 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
> [2] https://reviews.llvm.org/D54862#1308125
>
> Thanks in advance,
> Anastasia
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> 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/a4e9bc16/attachment.html>