[DRAFT] Deferred Allocation Prototype

[ThrudPrimrose]

This is possibly the start of a long PR that will evolve, and we should discuss it at every step.

The main idea is as follows (so far in the prototype):

Idea 1:
When an array is created, let's say "A", then also a size array is created "A_size". The Size array is always one-dimensional and contiguously stored. When there is an A_size -> A (IN connector needs to be _size), we trigger a reallocation operation and not a copy operation. I am not sure if we should have an A_size array, I would like to discuss this.

I have a small SDFG that shows what it looks like.

import dace

def one():
    sdfg = dace.sdfg.SDFG(name="deferred_alloc_test")

    sdfg.add_array(name="A", shape=("__dace_defer", "__dace_defer"), dtype=dace.float32, storage=dace.dtypes.StorageType.Default, transient=True)

    state = sdfg.add_state("main")

    an_1 = state.add_access('A')
    an_1.add_in_connector('IN_size')

    an_2 = state.add_scalar(name="dim0", dtype=dace.uint64)
    an_3 = state.add_scalar(name="dim1", dtype=dace.uint64)

    s_an_1 = dace.nodes.AccessNode(data="A_size")
    state.add_node(s_an_1)
    s_an_2 = dace.nodes.AccessNode(data="A_size")
    state.add_node(s_an_2)
    state.add_edge(s_an_1, None, s_an_2, None,
                dace.Memlet(None) )

    state.add_edge(s_an_2, None, an_1, 'IN_size',
                dace.Memlet(expr="A_size[0:2]") )

    state.add_edge(an_2, None, s_an_1, None,
                dace.Memlet(expr="A_size[0]") )
    state.add_edge(an_3, None, s_an_2, None,
                dace.Memlet(expr="A_size[1]") )


    sdfg.save("def_alloc_1.sdfg")
    sdfg.validate()

    return sdfg

s = one()
s.generate_code()
s(dim0=512, dim1=512)

Generated code looks like follows:

And SDFG:

Next Step:
Not 100% of this array will always be used; for example, when calling realloc, only the "__dace_defer" dimensions will be read from the array. And the dimensions that are passed using symbols will be read from the respective symbols (this can't be changed throughout the SDFG). (I am currently working on this step)

[tbennun]

I would not use IN_size (i.e., a throughput connector), maybe use just size.

[ThrudPrimrose]

I would not use IN_size (i.e., a throughput connector), maybe use just size.

About the connector, we can also read the size, then this will be "OUT_size" I had planned. Would still suggest both connectors to be named size?

[tbennun]

I would not use IN_size (i.e., a throughput connector), maybe use just size.

About the connector, we can also read the size, then this will be "OUT_size" I had planned. Would still suggest both connectors to be named size?

yes, exactly. Since those connectors are endpoints, and not flowing through the access node (as they would in a scope node).

[ThrudPrimrose]

I would not use IN_size (i.e., a throughput connector), maybe use just size.

About the connector, we can also read the size, then this will be "OUT_size" I had planned. Would still suggest both connectors to be named size?

yes, exactly. Since those connectors are endpoints, and not flowing through the access node (as they would in a scope node).

I was updating the implementation according to a discussion we had with Torsten and Lex. I also changed the implementation to use "size" for both in and out connectors. Now the problem is that this SDFG does not validate because the access node has duplicate connectors. I think it is better to make the size connectors distinct rather than changing the validation rules. Or should I update the validation procedures with access nodes being an exception?