Add language to the UPC spec. to further explain/constrain upc_localsizeof semantics

[Former user]

Originally reported on Google Code with ID 14 ``` This proposal is responsive to issue 34:

34. What are the semantics of upc_localsizeof() in a dynamic threads environment? See: https://upc-bugs.lbl.gov/bugzilla/show_bug.cgi?id=2960

The gist of the cited bug report is that, per the specification: 1. upc_localsizeof is an operator returning an integer constant value that is an upper bound on the amount space that must be allocated per thread for the given shared type or expression.

2. The fact that it must return a compile-time constant is demonstrated by the fact that this example is valid UPC:

shared [50] int (*r)[100]; shared [upc_localsizeof(*r)] char (*tmpR)[THREADS];

3. The specification doesn't explicitly state what should be returned by upc_localsizeof in the following example.

shared [50] int (*r)[100]; upc_localsizeof(*r);

If upc_localsizeof() were implemented such that its value is implemented at runtime, it could provide the lowest possible upper bound for the object pointed to by 'r'. However, since it is constrained to return a compile-time integral constant, it must return the same value as would be returned if THREADS=1, because that is the maximal value that will work for all dynamically specified values of THREADS.

4. The specification states the following: "the value is an upper bound of the size allocated with affinity to any single thread and may include an unspecified amount of padding."

Is 'unspecified amount of padding' overly broad? Could it be further constrained to, for example state that in the static threads compilation environment it returns the lowest possible upper bound for allocation on each thread, and in the dynamic threads case it is constrained to return the same value as the static THREADS compilation case when THREADS=1?

```

Reported by `gary.funck` on 2012-05-21 00:03:52

[Former user]

``` I support the interpretation which I reached for BUPC's implementation, which is the subject of the bugzilla link Gary has provided.

This includes the "return THREADS=1 value in dynamic threads environment" aspect as it seems to be the only way to resolve the "constant" and "upper bound" constraints. However, it does greatly reduce the usefulness of this operator.

To ensure backward-compatibility, I would suggest that any proposal to provide a RUNTIME constant interpretation must do so by introducing a new function/operator rather than revising the definition of this existing one. I think that doing so would be GOOD because the "tight" bound is more likely to be useful to the programmer (for instance to allocate memory). The idea of a upc_threadsizeof(object,thread) function appeals to me in this context. ```

Reported by `[e-mail]` on 2012-05-22 00:50:50

[Former user]

``` Just as a reminder, the UPC core library already includes a runtime exact-value version of upc_localsizeof:

size_t upc_affinitysize(size_t totalsize, size_t nbytes, size_t threadid); 2 upc affinitysize is a convenience function which calculates the exact size of the local portion of the data in a shared object with affinity to threadid.

this is intended to handle any cases that don't require a compile-time value (eg dynamic memory allocation, array iteration, etc), and in my opinion is already far more valuable to "real" applications than upc_localsizeof which is based entirely on hard-coded static array bounds.

Given upc_affinitysize, any proposal to change upc_localsizeof should be motivated entirely by its use for generating compile-time constants (ie for use in static allocation).

Is 'unspecified amount of padding' overly broad? Could it be further constrained

to, for example state that in the static threads compilation environment it returns the lowest possible upper bound for allocation on each thread,

Because it's an "unspecified" amount of padding, implementations are already free to provide a tighter upper bound when they can. This seems like a quality of implementation issue and not one that needs to be codified in the spec. ```

Reported by `danbonachea` on 2012-06-15 16:53:00

[Former user]

``` Although I like (and prefer) the idea of extending upc_localsizeof to accommodate the dynamic threads case as well, I agree with Dan that upc_affinitysize already fits that bill. I also agree that since that the "best fit" behavior is un-specified that there is no need to take further action. That said, a note to implementors might prove helpful, but perhaps such guidance would best fit into a "rationale" document, which would be maintained separately from the specification.

Closing this issue as "no change" required.

```

Reported by `gary.funck` on 2012-06-28 19:43:42 - Status changed: `NoChange` - Labels added: Milestone-Spec-1.3