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

Fri Dec 7 04:00:45 PST 2018

Hi JF,

> 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 can imagine that code can be written differently for different memory segments. For example if caches are used you might want to explore data locality or if memory banks are used you might want to exploit memory coalescing.

But my biggest problem at the moment is that Clang can't even preserve the address spaces of 'this' to make C++ for architectures with memory segments usable. We can't always rely on the optimizers to put objects in the right memory or perhaps we don't even always have such strong optimizer support.

> 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 have been looking at several options and we had some discussions with John too. Therefore I am suggesting to work on a second option as well that will target the situation where no manual tuning of the method definition for a specific memory segment is required. But I imagine this will take quite a while and I would like to offer some workable solution to the Clang users in the meantime (hopefully soon!).

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

Do you have any specific idea in mind? I am happy to explore the options further.

Thanks,

Anastasia

________________________________
From: jfbastien at apple.com <jfbastien at apple.com> on behalf of JF Bastien <jfbastien at apple.com>
Sent: 06 December 2018 17:41
To: Anastasia Stulova
Cc: cfe-dev; nd
Subject: Re: [cfe-dev] [RFC] Solution for preserving the address space of ‘this’ in C++ methods

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181207/4f00021c/attachment.html>