Python frontend should use storage type of array to determine map schedule

[tbennun]

@alexnick83
In the following example, the storage types of the output arrays are well-inferred:

@dace.program
def add(a: dace.float32[10, 10] @ dace.StorageType.GPU_Global, 
        b: dace.float32[10, 10] @ dace.StorageType.GPU_Global):
    return a + b @ b

add.to_sdfg().view()

However, the map generated by a + b would have the Default schedule, which translates to a CPU map, which subsequently crashes.

Additionally, the following code should probably fail gracefully, due to the output storage / computation schedule not being able to be inferred:

@dace.program
def add(a: dace.float32[10, 10] @ dace.StorageType.GPU_Global, 
        b: dace.float32[10, 10]):
    return a + b

but it doesn't fail.

[FlorianDeconinck]

+1

Hit this multiple times in different occasion. The worst is that it can manifest as a host code accessing device memory, crashing in non-obvious way for non GPU native coders.

Another example would be:

a_device_array = np.min(a_device_array , 0.0)

Here the coder mistake of using np.min instead of np.minumum leads to the generation of a reduction, which crashes because it thinks a_device_array can be host accessed