-
Notifications
You must be signed in to change notification settings - Fork 64
Description
Context on how the SAT planner works at the top of this file
Currently the op_list_converter function is used to assign file names. This function does a bad job: it can't nicely handle the case where multiple files have the same state. For example, if there is file f1.state1 and f2.state1 and an op taking a file in state1, the planners do not know which file to provide to the op
There is no way for planners to resolve the ambiguity of how to assign filenames to states on its own. Here are some ideas for solutions:
- Add another way for the user to add constraints on which op outputs are used as inputs to other ops. This constraint can then be encoded in a planner. Here's an ill-formed idea for the SAT planner. The filename selection itself can be encoded in a similar way to how op names are encoded (these are effectively the same problem as two ops can have the same signature, the extra constraints corresponding to the
througharg fud2 takes). This technique requires the number of filenames for a given state to be known up front when creating an instance. Choosing some reasonable constant is maybe okay here. I haven't fully thought through this idea and this technique might not work or be really complicated. - Add another way for the user to add constraints as above, but do some post processing file renaming step based on these constraints which is more cleaver than the current
op_list_converter. - Make the mapping from filenames to states unambiguous by adding constraints on which ops can exist. One way to do this is by adding a new type of op argument, a "set of a state argument". This lets that op take in an unordered list of files in a given state (for example, maybe the op is
gccand it's set argument is an unordered list of C files, files with the "C" state). If the planner includes the constraint that if an op in a plan has a return value or argument of state "s", there can be no other ops with a return value an argument of state set of "s", then the file mapping can be made unambiguously (as the set is unordered).
I personally like the last idea the best, though unlike the other two, it requires work across fud2's stack (the scripting language frontend and the backend). The second idea is likely the easier and the first is probably the hardest. Maybe there are more ideas I'm missing.