I noticed that
memref.assume_alignment does not specify memory effects. Analyses are forced to treat it conservatively and assume it has all possible side effects, which isn’t desirable. Any code motion across
assume_alignment is impossible and it spurious synchronization may be generated in the parallel case because of it. Conceptually, this op is pure. However, we cannot mark it as such because generic DCE will remove it (pure and no results).
Any suggestions on what effects should this have to both prevent DCE and allow for code motion? I was thinking of a giving it an effect on a non-default resource.
cc: @River707 @mehdi_amini who were involved in the ⚙ D74378 [MLIR] Add std.assume_align op. that added the op.
This is an interesting question, and I think the IR is missing modelling a trait. Any such
assume* ops that provide useful information for analyses and optimizers are actually pure and can be DCEd (in fact, they are no-ops/dead at some point later). An
AnalysisEffect trait can perhaps be introduced and attached to such ops so that the dead code elimination in
canonicalize/rewrite drivers doesn’t erase them. Only the op’s dialect’s conversion pass/method should be able to lower (erase) them out.
wouldOpBeTriviallyDead should be updated I think to not consider such ops dead when they have this trait: they are dead from an imperative execution standpoint but not from an informational one.
(disclaimer: I have no idea how it’s currently being used and how it interacts with llvm)
memref.assume_alignment semantics and add a return value, so this alignment assumption will only apply to result and not to input.
In this case it would be possible to just make it pure and it will interact nicely with DCE and CSE.
I would look into this direction as well if possible.