Support PGAS C in extern blocks

[mppf]

Since extern blocks are compiled by a version of clang embedded in the Chapel compiler, we can control the dialect of C used there. In particular, with --llvm-wide-opt compilation strategy, we can easily mark pointers in clang as referring to possibly-remote memory, since these simply need an attribute indicating that they are in a different address space. Since we use clang to generate LLVM IR, the existing LLVM pass we use to convert loads/stores on these special address spaces to GET and PUT will still function.

The "extension" to C we would need for PGAS C

• is small because it wouldn't create tasks or support active messages
• is probably already implemented in clang (attribute syntax to specify address space)
• can be implemented with macros to have a stable user-facing API (in case details of address space representation change).
• the Chapel compiler can determine which C functions need wide pointers based on how the functions are used.

This would allow an alternative solution to issue #11288.

For example:

extern {
  static inline int getValue( CHPL_WIDE_PTR(int) ptr) {
    return *ptr;
   }
}

var x: c_int;
on Locales[numLocales - 1] {
  var z = getValue(c_ptrTo(x));
}

The chapel compiler could transparently handle converting *ptr into a GET with existing techniques.

Additionally, we could consider automatically widening pointers when the Chapel compiler sees that as necessary, so that the following program could work:

extern {
  static inline int getValue( int* ptr) { // int* automatically widened based on use below
    return *ptr;
   }
}

var x: c_int;
on Locales[numLocales - 1] {
  var z = getValue(c_ptrTo(x));
}

[ronawho]

I'm really not a fan of extern blocks to begin with and adding this support seems like a huge mistake to me.

I do not like supporting arbitrary C and Chapel interop in this manner and I think this is an unreasonable extension that will be extremely difficult for any future Chapel implementations to support. I much prefer supporting things like c2chapel and sanity checks for non-local access.

[mppf]

@ronawho - is your concern about the usability or the implement-ability of this proposal / extern blocks?