core: implement EffectInstance

[PapyChacal]

Up until now, xDSL's implementation of side-effects only expressed effect kinds, that is, this operations reads, but never restricting what it effects.

This implements EffectInstance, which contains both an effect kind and an optional effected value, which can be an SSAValue (the effect only affect what this value represents, e.g., read from this memref only) or a SymbolRef (e.g., globals!)

This is used to consider allocation effects in generic DCE: an unused operation only allocating values it defines can safely be regarded as dead.

Also, state this property on stencil.alloc to let generic DCE erase unused allocations rather than a specific canonicalization pattern.

NB: I intend to use it to simplify the implementation of finer stencil bufferization analyses.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.83%. Comparing base (fab70a7) to head (3fca062).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2987      +/-   ##
==========================================
- Coverage   89.84%   89.83%   -0.01%     
==========================================
  Files         411      411              
  Lines       51641    51641              
  Branches     8027     8028       +1     
==========================================
- Hits        46399    46394       -5     
- Misses       3961     3964       +3     
- Partials     1281     1283       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[superlopuh]

Code looks good, how closely does this change mirror the MLIR mechanism?

[PapyChacal]

Code looks good, how closely does this change mirror the MLIR mechanism?

Good question ahah

So on previous bits, I was convinced to implement RecursiveMemoryEffect in terms of MemoryEffect, recursively returning nested effects as one's own effects. (As opposed to MLIR's design where it is a distinct trait, handled specifically in each effect-related analysis)

The only difference on this PR's bit is about those allocation effects' treatment in dead coda analysis; because MLIR actually recurse in that test, it only removes allocation effects of one operation if it's about its result (slightly cheaper to do I believe); here, I actually remove more effects from the "faulty" list in dead code analysis, be removing any allocation effect affecting a value defined by the effecting operation or any nested operation, to properly reuse this recursive effect query. This relies on MLIR's Value Scoping, more precisely:

values defined in a region don’t escape to the enclosing region, if any.

[superlopuh]

It would be good to document this difference a bit more in a comment in the code