Inspired by what AArch64 does for shifts, this patch attempts to replace shift amounts with neg if we can.
This is done directly as part of isel so its as late as possible to avoid breaking some BZHI patterns since those patterns need an unmasked (32-n) to be correct.
To avoid manual load folding and custom instruction selection for the negate. I've inserted new nodes in the DAG above the shift node in topological order. Though as I'm writing this, I'm wondering if it might make more sense to put them above the original shift amount node instead. By inserting them in the topogical order we should be able to run isel on them independently.
This patch does risk leaving behind a subtract and creating a negate if the subtract was used by something other than a shift.
Why? I would think we can simply add one more pattern to the BZHI?
I think this is bad because it not only not "messing up a BZHI pattern",
but anything else too, since it does not check that the user is and %val, %mask.