Sat May 18 08:41:23 EDT 2019


So it's already established that:

- all accumulator references are "full triangle".

- replacing triangles with single (or multiple) accumulators is an
  optimization that can be derived directly from the usage pattern.
  e.g. if 1) inside the loop only the last acc value is referenced and
  2) outside the loop only the last element is referenced.

So the only necessary bit here is to make them representable.

Instead of transforming indices, transform the arrays.  This popped
out through a notational shortcut.

There are a couple of inconsistences.

During construction, there is a loop index.  However, after
construction is finished (e.g. in the next loop, or just using an
input array), it is not clear how to refer to particular elements in
the arrays.

What is clear is that arrays have definite types.

Some rules:

- iteration ranges are always derived from the dimensions of the
  arrays that are being constructed in a loop.  all of these arrays
  are necessarily the same size.

- they are not necessarily related to arrays that are used as input to
  a loop.  this needs to be represented somehow.

- some dimensions are only there in a virtual sense.

What about leaving all the indices as they are in the code, but keep
track about which dimensions are actually implemented based on the
access patterns?

Basically, abstract the array access.

This keeps the original semantics.

So next step is to represent abstract array access.

There are two "stages"
- array is defined: random access is allowed
- array is being defined: only back-referencing acces is allowed

( Note: it is important to be able to nest triangles, i.e. one loop
builds up an array one element at a time, while allowing a sub-loop to
run over all the elements that have been computed up to that time. )

Based on the kind of access, the arrays can be thinly provisioned.