[WIP] Dynamic TT attributes

[devreal]

Implement a generic interface for attributes in TTs. An attribute may store either a value of specified type or a function mapping a task id to a value. Attributes may be set dynamically, i.e., the value and function can be changed at runtime. Setting a value or function overrides any previously set value or function.

Attributes availabe so far:

• Process mapping (deprecates set_keymap)
• Priority (deprecates set_priomap)
• Final * (the task won't spawn any new tasks; not sure how useful this is)
• Source * (the task has no predecessors; not sure how useful this is)
• Immediate * (the task may be executed immediately; useful for operation with short runtimes)

(*) not yet implemented

We may want to add an attribute to denote pure tasks once we support them.

Attributes are set using

tt->set_attribute<ttg::Attribute::<ATTRIBUTE>>(<priority-value>)

or

tt->set_attribute<ttg::Attribute::<ATTRIBUTE>>([](const TaskId& id){ return <priority-value-of-id>; })

These attributes are currently defined for TTs. Should they be specific to an op, i.e., do we want different attributes for op and op_cuda?

Do we want attributes on a per-terminal basis? Which ones?

[devreal]

Ideas for per-terminal attributes:

• Reducer functions (if we want to treat them as such)
• Whether reducers can be executed concurrently. The current use of streaming terminals in MRA is an example where the reducer can be executed in parallel, as each invocation sets a distinct entry in an array. This could alleviate some of the thread synchronization.

[devreal]

Discussion at the meeting Roanoke (2/4/2022): we can probably replace this with a policy-based design where the user overrides the default policy class and template the TT on it to allow the compiler to fully inline mapping functions.

[therault]

Superseded by PR #226