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

Wed Dec 12 11:10:52 PST 2018

Hi Richard,

Thanks again for sharing this, it seems like this technique should generally work for the address spaces apart from I am not very convinced about the superfluous template instantiation problem described at the end of the report. As address spaces are used widely on architectures with memory segments (either explicitly or implicitly) I would quite like to offer the solution that avoids unnecessary code duplication both at the source level and object code level too (at least by avoiding extra template instantiation caused by other differences in a type unrelated to address space quals).

The method qualifiers approach is quite appealing because it's cheap enough to implement and it's completely free from any unnecessary code duplication during the compilation. So it still seems to me like the best possible option at this very moment. In a long term I would, however, quite like to explore the idea from John about templating on address space qualifiers that should allow to eliminate both problems with the replication.

Btw, what is our generation strategy with prototyping/implementing the new proposals to the spec. At what stage would it be acceptable?

Cheers,
Anastasia

________________________________
From: Richard Smith <richard at metafoo.co.uk>
Sent: 06 December 2018 17:54:31
To: JF Bastien
Cc: Anastasia Stulova; nd; cfe-dev
Subject: Re: [cfe-dev] [RFC] Solution for preserving the address space of ‘this’ in C++ methods

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<mailto: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<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<mailto: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<mailto: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<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev