cmd/compile: migrate amd64-specific optimizations to generic optimizations

[josharian]

There are many optimizations in amd64.rules that apply to many architectures. As we add architectures, it'd be nice not to repeat discovering and encoding these rules.

To pick an example at random:

(ANDLconst [c] (ANDLconst [d] x)) -> (ANDLconst [c & d] x)

This could probably be done in generic.rules by introducing generic AndNNconst ops.

In some cases, we'd still need the arch-specific rules because optimizable patterns are introduced during lowering. If there are enough of those cases, it might be worth introducing common lowered ops and common lowered optimizations. The best way to find out it to start migrating rules and see.

cc @cherrymui @dr2chase @randall77 @brtzsnr

[randall77]

We can do this in generic rules like:

(And32 (And32 x (Const32 [c])) (Const32 [d])) -> (And32 x (Const32 [c&d]))

(and the symmetries thereof.)

I think we should do these as much as possible in generic.rules. These rules were originally put in AMD64.rules because ANDL gets generated by the shift lowerings. That may not be the case for all architectures.

[brtzsnr]

Regarding optimizing chains of AND/ADD/XOR/OR: there was a paper (I need to look it up again) that described how to do this for general case instead of having many rewrite rules for every usecase. We might want to implement that as separate pass.

[randall77]

I'm going to close this.
We do lots of constant folding in generic.rules now. For example, this rule handles the original report:

(And32  (Const32 [c])  (Const32 [d]))  -> (Const32 [int64(int32(c&d))])

I'm not sure what else might be done for this issue. Someone could do a pass to see if there are rules in the arch-specific files which are redundant with the generic rules, and where those lowered ops aren't introduced by other lowering rules. Seems not worth people's time.

It would be nice to have a general "rule can't ever fire" detector, which would catch this case and others. I had a rule coverage CL working at one point. It helped, but there's enough weird rules that all.bash doesn't cover everything (maybe it should, but that's a different issue).