Change Details

Currently, when we process the pattern like %cmp = icmp slt i64 %x, 0 select i1 %cmp, i32 -1, 32 1 We handle it in a general case with power of two being in the 3rd pard of select, and the generated code for this case looks like: %1 = lshr i64 %x, 62 %2 = trunc i64 %1 to i32 %3 = and i32 %2, 2 %4 = xor i32 %3, 2 %5 = add nsw i32 %4, -1 However we have a smarter logic specifically with comparison with zero in foldSelectInstWithICmp which did not apply because of type mismatch between `%x` and `1`. If we lift the restriction and handle this case separately, we end up with a better pattern: %1 = ashr i64 %x, 63 %2 = trunc i64 %1 to i32 %3 = and i32 %2, -24 %4 = or i32 %3, 19 This is 1 instruction less than what we have now. This patch relaxes the restricton on types, allowing now `%x` be wider than the result of select. We can in theory also allow `1` to be wider (no functional problems with that), however when I did, in some cases we end up with a worse code (see the comment). The problem looks irrelevant to this change which is a pure improvement. We can yield the last restriction when other problematic transforms are fixed.

Currently, when we process the pattern like %cmp = icmp slt i64 %x, 0 select i1 %cmp, i32 -1, 32 1 We handle it in a general case with power of two being in the 3rd pard of select, and the generated code for this case looks like: %1 = lshr i64 %x, 62 %2 = trunc i64 %1 to i32 %3 = and i32 %2, 2 %4 = xor i32 %3, 2 %5 = add nsw i32 %4, -1 However we have a smarter logic specifically with comparison with zero in foldSelectInstWithICmp which did not apply because of type mismatch between `%x` and `1`. If we lift the restriction and handle this case separately, we end up with a better pattern: %1 = ashr i64 %x, 63 %2 = trunc i64 %1 to i32 %3 = or i32 %2, 1 This is 2 instructions less than what we have now. This patch relaxes the restricton on types, allowing now `%x` be wider than the result of select. We can in theory also allow `1` to be wider (no functional problems with that), however when I did, in some cases we end up with a worse code (see the comment). The problem looks irrelevant to this change which is a pure improvement. We can yield the last restriction when other problematic transforms are fixed.

Currently, when we process the pattern like %cmp = icmp slt i64 %x, 0 select i1 %cmp, i32 -1, 32 1 We handle it in a general case with power of two being in the 3rd pard of select, and the generated code for this case looks like: %1 = lshr i64 %x, 62 %2 = trunc i64 %1 to i32 %3 = and i32 %2, 2 %4 = xor i32 %3, 2 %5 = add nsw i32 %4, -1 However we have a smarter logic specifically with comparison with zero in foldSelectInstWithICmp which did not apply because of type mismatch between `%x` and `1`. If we lift the restriction and handle this case separately, we end up with a better pattern: %1 = ashr i64 %x, 63 %2 = trunc i64 %1 to i32 %3 = and i32 %2, -24 %4 = or i32 %32, 19 This is 12 instructions less than what we have now. This patch relaxes the restricton on types, allowing now `%x` be wider than the result of select. We can in theory also allow `1` to be wider (no functional problems with that), however when I did, in some cases we end up with a worse code (see the comment). The problem looks irrelevant to this change which is a pure improvement. We can yield the last restriction when other problematic transforms are fixed.