> On Nov 7, 2019, at 9:00 AM, Yonghong Song <yhs@xxxxxx> wrote: > [...] > Let us workaound this issue until we found a compiler and/or > verifier solution. The workaround in this patch is > to make variable 'ret' volatile, which will force a reload > and then '&' operation to ensure better value range. > With this patch, I got the below byte code for the loop, > 0000000000000328 LBB0_9: > 101: r4 = r10 > 102: r4 += -288 > 103: r4 += r7 > 104: w8 &= 255 > 105: r1 = r10 > 106: r1 += -488 > 107: r1 += r8 > 108: r2 = 7 > 109: r3 = 0 > 110: call 106 > 111: *(u32 *)(r10 - 64) = r0 > 112: r1 = *(u32 *)(r10 - 64) > 113: if w1 s< 1 goto -28 <LBB0_5> > 114: r1 = *(u32 *)(r10 - 64) > 115: if w1 s> 7 goto -30 <LBB0_5> > 116: r1 = *(u32 *)(r10 - 64) > 117: w1 &= 7 > 118: w1 += w8 > 119: r7 += 8 > 120: w8 = w1 > 121: if r7 != 224 goto -21 <LBB0_9> > Insn 117 did the '&' operation and we got more precise > value range for 'w8' at insn 120. Thanks for adding this information. > The test is happy then. > #3/17 test_sysctl_loop1.o:OK > > Signed-off-by: Yonghong Song <yhs@xxxxxx> Acked-by: Song Liu <songliubraving@xxxxxx>
