search for: conv5

...tMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. In the setup I am proposing all the entries including the one for (%dec -> SCEV) will be 'forgotten' before we exit getBackedgeTakenInfo(Loop) becau...

...(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. > > In the setup I am proposing all the entries including the one for (%dec -> SCEV) will be 'forgotten' before we exit getBackedgeTakenInfo(Lo...

...tMemoizedResults(PendingCache); >> I'm not 100% sure, but I suspect this will not work. >> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. In the setup I am proposing all the entries including the one for (%dec -> SCEV) will be 'forgotten' before we exit getBackedgeTakenInfo(Loop) becau...

...(PendingCache); > >>> I'm not 100% sure, but I suspect this will not work. >>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. > > In the setup I am proposing all the entries including the one for (%dec -> SCEV) will be 'forgotten' before we exit getBackedgeTakenInfo(Lo...

...nsert(V, S); > forgetMemoizedResults(PendingCache); I'm not 100% sure, but I suspect this will not work. forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. -- Sanjoy

...aa !0 %conv = zext i8 %1 to i32 %arrayidx1 = getelementptr inbounds i8* %0, i32 1 %2 = load i8* %arrayidx1, align 1, !tbaa !0 %conv2 = zext i8 %2 to i32 %3 = load i8** @q, align 4, !tbaa !2 <<< Can this load be bypassed by the store below? %4 = load i8* %3, align 1, !tbaa !0 %conv5 = zext i8 %4 to i32 %add = add i32 %conv2, %conv %add7 = add i32 %add, %conv5 %conv8 = trunc i32 %add7 to i8 store i8 %conv8, i8* @s, align 1, !tbaa !0 <<< Can this store bypass the above load? ret void } At the point of enquiry I have the following (lowered) instructions: x3df...

...>> >>>> I'm not 100% sure, but I suspect this will not work. >>>> forgetMemoizedResults will only remove the Value->SCEV mapping for the conservative cases, but in the test case you attached >>>> getZeroExtendExpr(S) tries to create a *new* SCEV for %conv5 (since I suspect the %conv5->mapping was removed by getBackedgeTakenInfo) but early-exits because zext(%dec) is present in UniqueSCEVs. >> >> In the setup I am proposing all the entries including the one for (%dec -> SCEV) will be 'forgotten' before we exit getBackedgeTake...

...i32 >  %arrayidx1 = getelementptr inbounds i8* %0, i32 1 >  %2 = load i8* %arrayidx1, align 1, !tbaa !0 >  %conv2 = zext i8 %2 to i32 >  %3 = load i8** @q, align 4, !tbaa !2 <<< Can this load be bypassed by the > store below? >  %4 = load i8* %3, align 1, !tbaa !0 >  %conv5 = zext i8 %4 to i32 >  %add = add i32 %conv2, %conv >  %add7 = add i32 %add, %conv5 >  %conv8 = trunc i32 %add7 to i8 >  store i8 %conv8, i8* @s, align 1, !tbaa !0 <<< Can this store bypass the > above load? Err, are you sure you're asking the right question? Given the...

...work, but the general problem will remain. -- Sanjoy On Thu, Feb 8, 2018 at 2:19 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Hi Sanjoy, > > > > SCEV is behaving inconsistently when forming SCEV for this zext > instruction in the attached test case- > > %conv5 = zext i32 %dec to i64 > > > > If we request a SCEV for the instruction, it returns- > > (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) > > > > This can be seen by invoking- > > $ opt -analyze -scalar-evolution inconsiste...

...t* %z, align 4 %8 = load float* %x, align 4 %conv = fpext float %8 to double %mul = fmul double %conv, 6.700000e-01 %9 = load float* %y, align 4 %conv3 = fpext float %9 to double %mul4 = fmul double %conv3, 1.700000e-01 %add = fadd double %mul, %mul4 %10 = load float* %z, align 4 %conv5 = fpext float %10 to double %mul6 = fmul double %conv5, 1.600000e-01 %add7 = fadd double %add, %mul6 %conv8 = fptrunc double %add7 to float store float %conv8, float* %res, align 4 %11 = load float* %res, align 4 %12 = load i32* %i, align 4 %idxprom = sext i32 %12 to i64 %arrayidx9...

Hi Sanjoy, SCEV is behaving inconsistently when forming SCEV for this zext instruction in the attached test case- %conv5 = zext i32 %dec to i64 If we request a SCEV for the instruction, it returns- (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) This can be seen by invoking- $ opt -analyze -scalar-evolution inconsistent-scev-zext.ll But when computing the backedge taken cou...

Hi Jochen, > My llvm version is 3.0 release. > I have a module generated by clang. When I optimize it, I first add an > inlining pass (llvm::createFunctionInliningPass), then these passes: > - own FunctionPass > - llvm::createPromoteMemoryToRegisterPass > - llvm::createInstructionCombiningPass > - llvm::createDeadInstEliminationPass > - llvm::createDeadStoreEliminationPass

...ry: %vecext = extractelement <4 x i32> %a, i32 0 %vecext1 = extractelement <4 x i32> %a, i32 1 %vecext4 = extractelement <4 x i32> %b, i32 2 %vecext7 = extractelement <4 x i32> %b, i32 3 %conv = sitofp i32 %vecext to float %conv2 = sitofp i32 %vecext1 to float %conv5 = sitofp i32 %vecext4 to float %conv8 = sitofp i32 %vecext7 to float %vecinit = insertelement <4 x float> undef, float %conv, i32 0 %vecinit3 = insertelement <4 x float> %vecinit, float %conv2, i32 1 %vecinit6 = insertelement <4 x float> %vecinit3, float %conv5, i32 2 %v...

...ad float* %x, align 4 > %conv = fpext float %8 to double > %mul = fmul double %conv, 6.700000e-01 > %9 = load float* %y, align 4 > %conv3 = fpext float %9 to double > %mul4 = fmul double %conv3, 1.700000e-01 > %add = fadd double %mul, %mul4 > %10 = load float* %z, align 4 > %conv5 = fpext float %10 to double > %mul6 = fmul double %conv5, 1.600000e-01 > %add7 = fadd double %add, %mul6 > %conv8 = fptrunc double %add7 to float > store float %conv8, float* %res, align 4 > %11 = load float* %res, align 4 > %12 = load i32* %i, align 4 > %idxprom = sext i32 %12...

Hi! My llvm version is 3.0 release. I have a module generated by clang. When I optimize it, I first add an inlining pass (llvm::createFunctionInliningPass), then these passes: - own FunctionPass - llvm::createPromoteMemoryToRegisterPass - llvm::createInstructionCombiningPass - llvm::createDeadInstEliminationPass - llvm::createDeadStoreEliminationPass - new llvm::DominatorTree() - new

....i: ; preds = %if.then.i.i.i.i.i, %for.body.i.i.i.i.i %bits.1.i.i.i.i.i = phi i16 [ %conv2.i.i.i.i.i, %if.then.i.i.i.i.i ], [ %bits.024.i.i.i.i.i, %for.body.i.i.i.i.i ] %conv3.i.i.i.i.i = zext i16 %194 to i32 %shl.i.i.i.i.i = shl nuw nsw i32 %conv3.i.i.i.i.i, 1 %conv5.i.i.i.i.i = zext i16 %bits.1.i.i.i.i.i to i32 %and6.i.i.i.i.i = lshr i32 %conv5.i.i.i.i.i, 1 %and6.lobit.i.i.i.i.i = and i32 %and6.i.i.i.i.i, 1 %storemerge.in.i.i.i.i.i = or i32 %and6.lobit.i.i.i.i.i, %shl.i.i.i.i.i %storemerge.i.i.i.i.i = trunc i32 %storemerge.in.i.i.i.i.i to i16 store i...

...0 >> %vecext1 = extractelement <4 x i32> %a, i32 1 >> %vecext4 = extractelement <4 x i32> %b, i32 2 >> %vecext7 = extractelement <4 x i32> %b, i32 3 >> %conv = sitofp i32 %vecext to float >> %conv2 = sitofp i32 %vecext1 to float >> %conv5 = sitofp i32 %vecext4 to float >> %conv8 = sitofp i32 %vecext7 to float >> %vecinit = insertelement <4 x float> undef, float %conv, i32 0 >> %vecinit3 = insertelement <4 x float> %vecinit, float %conv2, i32 1 >> %vecinit6 = insertelement <4 x float>...

...8 signext %a, i8 signext %b) local_unnamed_addr #0 { entry: %conv = sext i8 %a to i32 %and = and i32 %conv, 1 %cmp = icmp eq i32 %and, 0 %conv1 = zext i1 %cmp to i32 %conv2 = sext i8 %b to i32 %cmp3 = icmp eq i32 %conv2, 0 %conv4 = zext i1 %cmp3 to i32 %or = or i32 %conv1, %conv4 %conv5 = trunc i32 %or to i8 ret i8 %conv5 } ; Function Attrs: nounwind ssp uwtable define signext i8 @goo_before_InstCombine(i8 signext %a, i8 signext %b) local_unnamed_addr #0 { entry: %conv = sext i8 %a to i32 %and = and i32 %conv, 1 %cmp = icmp ne i32 %and, 0 %conv1 = zext i1 %cmp to i32...

...work, but the general problem will remain. -- Sanjoy On Thu, Feb 8, 2018 at 2:19 PM, Chawla, Pankaj <pankaj.chawla at intel.com> wrote: > Hi Sanjoy, > > > > SCEV is behaving inconsistently when forming SCEV for this zext instruction > in the attached test case- > > %conv5 = zext i32 %dec to i64 > > > > If we request a SCEV for the instruction, it returns- > > (zext i32 {{-1,+,1}<nw><%for.body>,+,-1}<nw><%for.body7> to i64) > > > > This can be seen by invoking- > > $ opt -analyze -scalar-evolution inconsiste...

I have added a few PPC-specific DAG combines in the past that follow this pattern on specific operations. Now that it appears that this would be useful to do on yet another operation, I'm wondering what people think about doing this in the target-independent DAG Combiner for any legal/custom operation on the target. TL; DR; The generic pattern would look like this: (build_vector (op