telamon

telamon copied to clipboard

We want to distinguish functions being created from functions which are fully created ("frozen"). It should not be possible to add instructions or other objects to frozen functions. This is because we want to have a complete view of all possible choices (including choices induced by e.g. lowering) even before starting the exploration.

Currently this is implemented with a somewhat ugly hack using a "Lowering" type which is unit for non-frozen functions and contains lowering information (mapping from initial dimensions to lowered dimensions) for frozen functions. This was done in order to minimize the amount of needed code churn to the previous code (which handled only non-frozen functions) but is very counterintuitive.

We should refactor the Function / Instruction / etc. architecture (possibly using a common trait and specialized sub-traits, or by somehow wrapping things with lowering information) in order to make the distinctions as well as the common elements more explicit.

I think the best option would be to avoid modifying the function during the whole execution. There is currently two reasons why the function may be modified during the search:

1. to add existing objects to other sets
2. to create new objects

For 1), we could modify TelamonGen so the domain keeps track of the sets itself. We would just give the information on how to initialize the set instead of providing a storage for them. A nice thing is that it would also simplify the telamon::ir module by removing the book-keeping code that currently manages the sets and it would make it easier to port Telamon to new IRs/targets.

For 2), we could create the additional instructions/loops but not insert them in the function. It would still works as long as TelamonGen knows how to fetch them.

If this works, then the freezing code is not necessary anymore. The search space will hold a non-mutable reference to the function that guarantees it is not modified during the exploration. We will still need to precompute the potential new objects but not to freeze the function.

Actually, we might even be able to share the newly allocated objects between all branches of the search tree, provided they are always created the same.

That being said, I don't think we have the time/resources to do that in the near future.