[opt] Neg canonicalization, abs equals zero optimization.

[cdleary]

• Canonicalize add(not(x), 1) => neg(x)
• Optimize eq(sel(p, cases=[x, neg(x)]), 0) => eq(x, 0) (for nez as well)

[ericastor]

BTW: we've started to think it would be helpful to just add an absolute-value unary operation to XLS IR, so we can canonicalize to it & model it more easily for various optimizations and analyses... without relying on detecting the exact pattern sel(x < 0, cases=[x, neg(x)]). What do you think about taking this step in general?

[cdleary]

@ericastor Sounds totally reasonable and definitely like something that's worth us experimenting with! Also generally a pretty type-2 decision since we could always desugar it at some early point in the pipeline if we wanted to.

I think there's a natural tension between having fewer primitives (which you'd pick because then because the op representations are more universally present in the IR) vs having more clear composite operations because their aggregate properties are particularly interesting. E.g. for canonicalizing to neg I was wondering if then we'd miss any patterns that were smashing together add(x, $N) on account of negate "laundering" that inside.

But it never seems wrong to have a higher level primitive the user can opt to provide the system that "worst case it can do is lower".