search for: i95

In 3.1, the backend is very slow to legalize types. Following is the code snippet which may be the culprit: %Result.i.i.i97 = alloca i33, align 8 %Result.i.i.i96= alloca i33, align 8 %Result.i.i.i95 = alloca i33, align 8 %Result.i.i.i94 = alloca i33, align 8 %Result.i.i.i93 = alloca i33, align 8 %Result.i.i.i92= alloca i33, align 8 %Result.i.i.i91 = alloca i33, align 8 %Result.i.i.i90 = alloca i33, align 8 %Result.i.i.i89 = alloca i33, align 8 The compilation time improve signifi...

...r i32 %conv1.i90, 1 %conv2.i92 = trunc i32 %or.i91 to i16 br label %if.end.i102 if.end.i102: ; preds = %if.then.i93, %for.body.i89 %bits.1.i94 = phi i16 [ %conv2.i92, %if.then.i93 ], [ %bits.024.i86, %for.body.i89 ] %conv3.i = zext i16 %13 to i32 %shl.i95 = shl nuw nsw i32 %conv3.i, 1 %conv5.i96 = zext i16 %bits.1.i94 to i32 %and6.i97 = lshr i32 %conv5.i96, 1 %and6.lobit.i = and i32 %and6.i97, 1 %storemerge.in.i = or i32 %and6.lobit.i, %shl.i95 %storemerge.i98 = trunc i32 %storemerge.in.i to i16 store i16 %storemerge.i98, i16* %x.addr.02...