see https://bugs.libre-soc.org/show_bug.cgi?id=731#c23 for context SwizzledSimdValue has emerged as an optimisation that, once SimdSignal version 1 has moved off of critical path and allowed multiple other developers to proceed with converting ALUs over to it, will become a high priority for reducing gate count. however as an optimisation it is currently classified as non-essential due to SimdSignal being a far higher priority critical path task. therefore this bugreport is being created with a series of high priority blockers that is it absolutely essential to complete first in order to move SimdSignal off off critical path, at which point this task's priority can be altered. this task will also be a "critical blocker" for the 2nd ASIC to make sure that it does get done, but done at an appropriately-scheduled time.
setting a very weird combination of "critical" importance but LOW priority, to recognise the fact that completing a version 1 SimdSignal is a much higher (critical path) priority. (edit: i also need to work out where the heck to get some budget from, for this. i know. NGI POINTER will do. solve that one later)