Require that at least one dimension of a shared array type or declaration is an integral multiple of the block size

[Former user]

Originally reported on Google Code with ID 17 ``` This proposal addresses issue 40.

40. The following declaration:

shared [4] int B[3*THREADS];

yields these results when compiled for a dynamic threads environment, and when executed with 3 threads.

THREADS: 3 size: 36 no. elements: 9 block size: 4 local size: 16

This is the correct language defined behavior. However, it demonstrates a non-intuitive result, where although the "threads multiple" is 3, the per−thread contribution is 4 elements because this is dictated by the block size. Should the specification require that the threads multiple is an even multiple of the block size? Otherwise, it seems that some rather non−intuitive impacts on performance might result?

Proposal:

Add a constraint to section 6.5.1.1 ("The shared and reference type qualifiers") that states that at least one dimension of a shared array must be an even multiple of the block size when the element type of the shared array is declared with a definite block size.

Impact:

There may be applications or tests that will not compile once this constraint is implemented by a conforming UPC compiler. As argued in the discussion above, there are potentially surprising performance characteristics of such definitions. That is the motivation for proposing this constraint.

```

Reported by `gary.funck` on 2012-05-21 01:15:50

[Former user]

``` I think that if UPC were intended to require some relationship between the layout qualifier and the array dimension(s) then it should have been in the 1.0 specification. For better or worse no such constraint has existed in the spec, and I believe that adding it now has the potential to break applications that rely on the independence of these two quantities.

I would not object to a compiler which warned by default (or with its -Wall equivalent) that "Array dimension is not divisible by its block size", but cannot sign-on to actually prohibiting this practice. ```

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

[Former user]

``` I do not support this change. There are codes, for instance, where the block size bears some relationship to the expected number of threads, rather than to the multiplier. ```

Reported by `brian.wibecan` on 2012-05-22 22:21:28

[Former user]

``` Re: "There are codes, for instance, where the block size bears some relationship to the expected number of threads, rather than to the multiplier."

Would you please explain more, or provide an example?

```

Reported by `gary.funck` on 2012-05-22 22:32:26

[Former user]

``` Here's an example:

shared [4] int STUFF[THREADS];

If the number of threads is a multiple of four, STUFF is divided evenly among the threads, without the distribution being strictly cyclic. Some algorithms expect a power-of-two number of threads, and many systems have a multiple-of-four number of processors per node, so this kind of expectation is easily met. ```

Reported by `brian.wibecan` on 2012-05-22 22:49:09

[Former user]

``` Based on the comments from Brian and me, I motion to Reject this proposal.

Gary, you are the reporter/owner of this issue. So, I defer to you to either make the Status change if you agree, or to continue the discussion if you want to keep this alive. However, I would strongly suggest that if this issue remains alive, that it be targeted for 2.0 due to the incompatibility with current applications. ```

Reported by `[e-mail]` on 2012-07-02 22:41:25

[Former user]

``` I agree with the consensus that this proposal be rejected, and have changed the status accordingly.

```

Reported by `gary.funck` on 2012-07-02 23:24:38 - Status changed: `Rejected` - Labels added: Milestone-Spec-1.3