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.
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.