[InstCombine] Fold conditional sign-extend of high-bit-extract into high-bit…


[InstCombine] Fold conditional sign-extend of high-bit-extract into high-bit-extract-with-signext (PR42389)

This can come up in Bit Stream abstractions.

The pattern looks big/scary, but it can't be simplified any further.
It only is so simple because a number of my preparatory folds had
happened already (shift amount reassociation / shift amount
reassociation in bit test, sign bit test detection).


  • There are two main flavors: https://rise4fun.com/Alive/zWi The difference is add vs. sub, and left-shift of -1 vs. 1
  • Since we only change the shift opcode, we can preserve the exact-ness: https://rise4fun.com/Alive/4u4
  • There can be truncation after high-bit-extraction: https://rise4fun.com/Alive/slHc1 (the main pattern i'm after!) Which means that we need to ignore zext of shift amounts and of NBits.
  • The sign-extending magic can be extended itself (in add pattern via sext, in sub pattern via zext. not the other way around!) https://rise4fun.com/Alive/NhG (or those sext/zext can be sinked into select!) Which again means we should pay attention when matching NBits.
  • We can have both truncation of extraction and widening of magic: https://rise4fun.com/Alive/XTw In other words, i don't believe we need to have any checks on bitwidths of any of these constructs.

This is worsened in general by the fact that we may have sext instead
of zext for shift amounts, and we don't yet canonicalize to zext,
although we should. I have not done anything about that here.

Also, we really should have something to weed out sub like these,
by folding them into add variant.



lebedevriOct 7 2019, 1:53 PM
rL373963: [InstCombine][NFC] Tests for "conditional sign-extend of high-bit-extract"…