<HTML><HEAD><TITLE>Samsung Enterprise Portal mySingle</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<STYLE id=mysingle_style type=text/css>P {
MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
TD {
MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
LI {
MARGIN-TOP: 5px; FONT-FAMILY: Arial, arial; MARGIN-BOTTOM: 5px; FONT-SIZE: 9pt
}
BODY {
LINE-HEIGHT: 1.4; MARGIN: 10px; FONT-FAMILY: Arial, arial; FONT-SIZE: 9pt
}
</STYLE>
<META name=GENERATOR content=ActiveSquare></HEAD>
<BODY>
<P>Hi Nick, <BR>I hand coded that IR. But thinking about it yes you might be right; anyhow gvn or cse would be run before vectorization and would catch these cases.<BR>I hand coded this IR as this was the reason that could come up with when i saw BBVectorizer using SCEV to compare the arguments instead of directly comparing them. I though direct comparision may miss few scenarios which SCEV compare can catch.</P>
<P>Is there any scenario where we might actually require to compare SCEV instead of directly comparing Value* ?</P>
<P>If not i will go ahead and modify the patch to compare the arguments directly. It would reduce the overhead to getting the SCEV for the argument.</P>
<P> </P>
<P>Thanks<BR>Karthik Bhat</P>
<P> </P>
<P>------- <B>Original Message</B> -------</P>
<P><B>Sender</B> : Nick Lewycky<nicholas@mxc.ca></P>
<P><B>Date</B> : May 21, 2014 17:59 (GMT+09:00)</P>
<P><B>Title</B> : Re: [PATCH] Add support to vectorize ctlz, cttz and powi intrinsics in SLPVectorizer</P>
<P> </P>Karthik Bhat wrote:<BR>> Hi Nadav,<BR>> Thanks for the review. We need to use SCEV as it will detect cases were the Value* may be different but underlying value may be same.<BR>><BR>> For e.g. i tried out the following example -<BR>> declare float @llvm.powi.f32(float, i32)<BR>> define void @vec_powi_f32(float* %a, float* %b, float* %c, i32 %A, i32 %B) {<BR>> entry:<BR>> %0 = alloca i32, align 4<BR>> %1 = alloca i32, align 4<BR>> %C = alloca i32, align 4<BR>> %D = alloca i32, align 4<BR>> store i32 %A, i32* %0, align 4<BR>> store i32 %B, i32* %1, align 4<BR>> %2 = load i32* %0, align 4<BR>> %3 = load i32* %1, align 4<BR>> %4 = add nsw i32 %2, %3<BR>> %5 = add nsw i32 %2, %3<BR>> store i32 %4, i32* %C, align 4<BR>> store i32 %5, i32* %D, align 4<BR>><BR>> %i0 = load float* %a, align 4<BR>> %i1 = load float* %b, align 4<BR>> %add1 = fadd float %i0, %i1<BR>> %call1 = tail call float @llvm.powi.f32(float %add1,i32 %4) nounwind readnone<BR>><BR>> %arrayidx2 = getelementptr inbounds float* %a, i32 1<BR>> %i2 = load float* %arrayidx2, align 4<BR>> %arrayidx3 = getelementptr inbounds float* %b, i32 1<BR>> %i3 = load float* %arrayidx3, align 4<BR>> %add2 = fadd float %i2, %i3<BR>> %call2 = tail call float @llvm.powi.f32(float %add2,i32 %5) nounwind readnone<BR>><BR>> %arrayidx4 = getelementptr inbounds float* %a, i32 2<BR>> %i4 = load float* %arrayidx4, align 4<BR>> %arrayidx5 = getelementptr inbounds float* %b, i32 2<BR>> %i5 = load float* %arrayidx5, align 4<BR>> %add3 = fadd float %i4, %i5<BR>> %call3 = tail call float @llvm.powi.f32(float %add3,i32 %5) nounwind readnone<BR>><BR>> %arrayidx6 = getelementptr inbounds float* %a, i32 3<BR>> %i6 = load float* %arrayidx6, align 4<BR>> %arrayidx7 = getelementptr inbounds float* %b, i32 3<BR>> %i7 = load float* %arrayidx7, align 4<BR>> %add4 = fadd float %i6, %i7<BR>> %call4 = tail call float @llvm.powi.f32(float %add4,i32 %4) nounwind readnone<BR>><BR>> store float %call1, float* %c, align 4<BR>> %arrayidx8 = getelementptr inbounds float* %c, i32 1<BR>> store float %call2, float* %arrayidx8, align 4<BR>> %arrayidx9 = getelementptr inbounds float* %c, i32 2<BR>> store float %call3, float* %arrayidx9, align 4<BR>> %arrayidx10 = getelementptr inbounds float* %c, i32 3<BR>> store float %call4, float* %arrayidx10, align 4<BR>> ret void<BR>> }<BR>><BR>> Here %4 and %5 are referring to same value. If we just compare (Value*) for equality it will not be able to vectorize the powi in the above code. But if we use SCEV compare it is able to conclude that %4 is actually same as %5 and hence vectorizes the powi intrinsic.<BR><BR>Overkill? All you need is CSE. Either opt -early-cse or opt -basicaa <BR>-gvn should clean that up.<BR><BR>Through what circumstances of transforms by passes did you end up with <BR>this IR? Is there a place that we should have caught it earlier? Is <BR>there a good way to rearrange the passes such that CSE is performed <BR>before vectorizing?<BR><BR>Nick<BR><BR>> The same approach is used in BBVectorizer to detect if arguments are equal for these intrinsics.<BR>><BR>> Thanks<BR>><BR>> http://reviews.llvm.org/D3851<BR>><BR>><BR>><BR>> _______________________________________________<BR>> llvm-commits mailing list<BR>> llvm-commits@cs.uiuc.edu<BR>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits<BR>><BR><BR>
<P> </P>
<P> </P><!--SP:kv.bhat--><!--kv.bhat:EP-->
<P> </P>
<TABLE id=confidentialsignimg>
<TBODY>
<TR>
<TD NAMO_LOCK>
<P><IMG border=0 src="cid:2XYNX48N0EB5@namo.co.kr" width=520></P></TD></TR></TBODY></TABLE></BODY></HTML><img src='http://ext.samsung.net/mailcheck/SeenTimeChecker?do=717a7c33c869fb52b85fd0ce6eed126e4a8c4f80000853b51046eb2a7007a79e6a34984216ac66b0a34d950c0c4aaac5e1f93dc7001c940a07805447a154a46fcf878f9a26ce15a0' border=0 width=0 height=0 style='display:none'>