Description
Description
This seems focused on single output Ops. It's the application of the node that destroys the input, not the computation of a specific output. For instance, in LU_factor which outputs both LU, and p we artificially specify that destroy_map is {1: [0]}, because {0: [0], 1: [0]} is not allowed (we get a mulitple destroyers error when introducing the inplace during rewrites).
We should check if anything in the codebase relies on a strict map from input to output. If not, our Ops could simply have a tuple for destroy_map indicating which inputs are being destroied, and not a dict from outputs to inputs like we have now.
Some Ops may be overloading this functionality to know for instance which of multiple outputs in being computed inplace of an input (such as in Elemwise) but this is information that could be stored elsewhere.
Otherwise, if this mapping is actually needed for something, we may need to extend the inplace consistency check to at least allow multiple outputs from the same node to destroy the same input.