A DXC optimization is producing i25 type, but shouldn't for DXIL

Description
An llvm optimization (like some switch optimization) is resulting in odd-sized int value types, such as i25. We should not produce integer values of odd sizes like this.

A separate but related issue for catching this class of problem in DxilValidation is #6563.

Steps to Reproduce

uint param;

bool fn()
{
    switch (param)
    {
    case 0:
    case 20:
    case 24:
        return false;
    }
    return true;
}

float4 main() : SV_Target
{
    float4 ret = float4(0, 0, 0, 0);
    if (fn())
    {
        ret = float4(1, 1, 1, 1);
    }
    return ret;
}

Actual Behavior
Results in IR containing i25:

  %6 = trunc i32 %3 to i25
  %7 = lshr i25 15728638, %6
  %8 = and i25 %7, 1
  %9 = icmp ne i25 %8, 0
  %10 = select i1 %9, float 1.000000e+00, float 0.000000e+00

This i25 type should never be produced during compilation or optimization.

Environment

• DXC version: latest main, not a regression
• Host Operating System: any

Start by compiling the provided HLSL reproducer with the latest DXC main and inspect the generated LLVM IR around the switch optimization. Trace the optimization that creates the i25 truncation and related operations; done means compilation and optimization no longer produce odd-sized integer value types such as i25.