You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to decide whether this is really worth it, i.e. is it too painful (and not enough of a good thing anyway) to require FuncDefn authors to declare what extensions they use. But there is at least some utility in that it's optional anyway.
This could be done with the same interface to that for DFGs/CFGs/etc. (using TO_BE_INFERRED: ExtensionId as per #1195), but the algorithm needs to be significantly more complicated:
Build a (directed) call graph of functions, each node has a lower-bound ExtensionSet of the non-Call leaf ops
Identify cycles - all functions on a cycle must have the same ExtensionSet, so "merge metas" (replace cycle with single node with lower-bound being the union)
Solve the unknowns - each is just union over the successors (things it must contain)
We need to decide whether this is really worth it, i.e. is it too painful (and not enough of a good thing anyway) to require FuncDefn authors to declare what extensions they use. But there is at least some utility in that it's optional anyway.
This could be done with the same interface to that for DFGs/CFGs/etc. (using
TO_BE_INFERRED: ExtensionId
as per #1195), but the algorithm needs to be significantly more complicated:This is very roughly what was in old #1137
The text was updated successfully, but these errors were encountered: