Changes

Summary

[CostModel][X86] Improve AVX1/AVX2 v16i32->v16i16/v16i8 truncation costs (PR51972) (details)
[InstCombine] move add after min/max intrinsic (details)

Commit 3538ee763d13a26515a224ddeb3a51a5af143e38 by llvm-dev [CostModel][X86] Improve AVX1/AVX2 v16i32->v16i16/v16i8 truncation costs (PR51972) Based off worst case btver2 (AVX1) and haswell (AVX2) llvm-mca reports
	llvm/test/Analysis/CostModel/X86/cast.ll
	llvm/test/Analysis/CostModel/X86/arith-fix.ll
	llvm/lib/Target/X86/X86TargetTransformInfo.cpp
	llvm/test/Analysis/CostModel/X86/arith-overflow.ll
	llvm/test/Analysis/CostModel/X86/trunc.ll
	llvm/test/Analysis/CostModel/X86/min-legal-vector-width.ll
Commit 6063e6b499c7829b941f94456af493a1ecb93ea1 by spatel [InstCombine] move add after min/max intrinsic This is another regression noted with the proposal to canonicalize to the min/max intrinsics in D98152. Here are Alive2 attempts to show correctness without specifying exact constants: https://alive2.llvm.org/ce/z/bvfCwh (smax) https://alive2.llvm.org/ce/z/of7eqy (smin) https://alive2.llvm.org/ce/z/2Xtxoh (umax) https://alive2.llvm.org/ce/z/Rm4Ad8 (umin) (if you comment out the assume and/or no-wrap, you should see failures) The different output for the umin test is due to a fold added with c4fc2cb5b2d98125 : // umin(x, 1) == zext(x != 0) We probably want to adjust that, so it applies more generally (umax --> sext or patterns where we can fold to select-of-constants). Some folds that were ok when starting with cmp+select may increase instruction count for the equivalent intrinsic, so we have to decide if it's worth altering a min/max. Differential Revision: https://reviews.llvm.org/D110038
	llvm/test/Transforms/InstCombine/minmax-intrinsics.ll
	llvm/lib/Transforms/InstCombine/InstCombineCalls.cpp