Reduce bswap to smaller type

[chfast]

In some cases where shift is followed by bswap the bswap type may be reduced.
E.g.

  %2 = zext i16 %0 to i64
  %3 = shl nuw i64 %2, 48
  %4 = tail call i64 @llvm.bswap.i64(i64 %3)
  %5 = trunc i64 %4 to i16

should just be

  %2 = tail call i16 @llvm.bswap.i16(i16 %0)

https://godbolt.org/z/fq9e591EM
https://alive2.llvm.org/ce/z/rskDKL

[RKSimon]

CC @rotateright @LebedevRI

https://alive2.llvm.org/ce/z/Qif2dE

Should we limit this to just being fed from a trunc or should this be a SimplifyDemandedBits driven fold?

----------------------------------------
define i64 @src(i16 %0) {
%1:
  %2 = zext i16 %0 to i64
  %3 = shl nuw i64 %2, 48
  %4 = bswap i64 %3
  %5 = and i64 %4, 65535
  ret i64 %5
}
=>
define i64 @tgt(i16 %0) {
%1:
  %2 = bswap i16 %0
  %3 = zext i16 %2 to i64
  ret i64 %3
}
Transformation seems to be correct!

[LebedevRI]

As a rule-of-thumb, relying on a trunc is always fragile, i think demandedbits may be better here.

[RKSimon]

Optimized codegen is handled in DAG by 370ebc9 but we should be trying to simplify IR in InstCombine as well

[rotateright]

Narrowing bswap in IR:
https://reviews.llvm.org/D122166

See also canonicalizing bswap+shift in IR:
https://reviews.llvm.org/D122010

[rotateright]

We get the motivating C source tests in IR now (and codegen), so we can close this report.
It is possible to go further (using known bits of the shift amount for example), so if that matters, please open a new issue.