The current Liveness analysis does not support operations with nested regions. This causes issues when querying liveness information about blocks nested within operations. Furthermore, the live-in and live-out sets are not computed properly in these cases.
This still does not handle the case where values flow through operations (and that is fine, we lack the interface). A good example might be a loop.for with iter_args
I am OK with this to land with the two comments addressed but wait for @rriddle to comment and approve.
What does it mean if there is no ownerBlock. Can this ever happen? It would mean that the use was in a block that does not have the current operation as parent. Values cannot escape regions, though. Maybe rather assert than hiding this case.
Is this a spurious reformat?
Use valueIds here?
I think this would be easier to read if the function arguments were already named %argX in the input. Also, please make the value names unique, either by using the counter or you could use an instruction position trace, using block numbers and trace back via parent ops.
i1@b0@i5 for the second instruction in block zero of the fifth instruction. These are easier to map back to the actual code than global numbers.
In any case, something to make the printout non-ambiguous.
Thanks for tackling this! Left a few comments.
nit: Use getUsers if you are only accessing the use owners.
Can you just add a utility Region::findAncestorOpInRegion(Operation *op) method that finds the ancestor of an operation within a given region? It's effectively similar to the block variant.
nit: Same here, can you change this to getUsers?
Are you trying to find an ancestor of useOperation that exists within block? Seems like block->findAncestorOpInBlock(useOperation) is intended for this use case.