I'm translating llvm's intermediate representation, after optimization, to the intermediate representation of another optimizer.  <br><br>One of the problems I've run into is that llvm sometimes (although rarely) produces strangely sized integers after an opt pass with -O3 (in this example, 832 bits).  I need to use 8, 16, or 32 bit integers for the other intermediate language.  In short, I'm wondering if there's a way to prevent opt from producing ridiculously sized integers, so that my code doesn't have to deal with them.<br>
<br>I tried to get a small sample of code to produce this problem, so that you'd have an example:<br><i><br></i><div style="margin-left:40px"><i>void gsm_print (unsigned char *c)</i><br><i>{</i><br><i>        short   xmc[52];</i><br>
<br><i>        xmc[19]  = (*c >> 2) & 0x7;</i><br><i>        xmc[22]  = (*c >> 1) & 0x7;</i><br><i>        xmc[24]  = (*c >> 3) & 0x7;</i><br><i>        xmc[28]  = (*c++ & 0x1) << 2;</i><br>
<i>        xmc[29]  = (*c >> 3) & 0x7;</i><br><br><i>        printf("%.2d %.2d %.2d\n", xmc[19], xmc[22], xmc[24]);</i><br><i>}</i><br></div><br>I used the following commands to produce the llvm optimized code:<br>
clang -std=c89 -ccc-host-triple mipsel-unknown-linux -msoft-float -ccc-clang-archs mipsel -S -emit-llvm  test-.c  -o test.cll<br>opt -S   -O3 test.cll -o test.ll<br><br>The 832 bit integer is introduced by OPT: <br><br><div style="margin-left:40px">
<i>; ModuleID = 'test.cll'</i><br><i>target datalayout = "e-p:32:32:32-i1:8:8-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-n32"</i><br><i>target triple = "mipsel-unknown-linux"</i><br>
<br><i>@.str = private unnamed_addr constant [16 x i8] c"%.2d %.2d %.2d\0A\00", align 1</i><br><br><i>define void @gsm_print(i8* nocapture %c) nounwind {</i><br><i>entry:</i><br><i>  %0 = load i8* %c, align 1</i><br>
<i>  %conv = zext i8 %0 to i32</i><br><i>  %shr13 = lshr i32 %conv, 2</i><br><i>  %1 = zext i32 %shr13 to i832</i><br><i>  %2 = shl nuw nsw i832 %1, 304</i><br><i>  %shr314 = lshr i32 %conv, 1</i><br><i>  %and4 = and i32 %shr314, 7</i><br>
<i>  %3 = zext i32 %shr314 to i832</i><br><i>  %4 = shl nuw nsw i832 %3, 352</i><br><i>  %shr815 = lshr i32 %conv, 3</i><br><i>  %5 = zext i32 %shr815 to i832</i><br><i>  %6 = shl nuw nsw i832 %5, 384</i><br><i>  %and13 = shl nuw nsw i32 %conv, 2</i><br>
<i>  %7 = zext i32 %and13 to i832</i><br><i>  %8 = shl nuw nsw i832 %7, 448</i><br><i>  %ins9 = or i832 %6, %8</i><br><i>  %ins6 = or i832 %ins9, %4</i><br><i>  %ins3 = or i832 %ins6, %2</i><br><i>  %mask = and i832 %ins3, 2907354897182427562473109274990997453148240953923409872292419068024036200676295656363596833343228648301157852525925214200579414210641920</i><br>
<i>  %sext17 = lshr exact i832 %mask, 304</i><br><i>  %conv2220 = trunc i832 %sext17 to i32</i><br><i>  %9 = lshr i832 %mask, 384</i><br><i>  %10 = trunc i832 %9 to i32</i><br><i>  %call = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([16 x i8]* @.str, i32 0, i32 0), i32 %conv2220, i32 %and4, i32 %10) nounwind</i><br>
<i>  ret void</i><br><i>}</i><br><br><i>declare i32 @printf(i8* nocapture, ...) nounwind</i><br></div><br>Do I have to implement logic for extremely large integers, or is there a way to limit the size of the integers that opt produces?<br>