I would suggest you file a bug for this if you haven't already.
This is rather odd code to be generating. Is this coming from another
opto pass or the frontend? I might be tempted to see if the source is
easy to tweak.
Philip
On 04/01/2014 04:16 PM, Mark Schimmel wrote:>
> for.body: ; preds = %for.body.lr.ph, %for.body
>
> *_ %ACC.sroa.0.013 = phi i64 [ 0, %for.body.lr.ph ], [ %phitmp9,
> %for.body ]_*
>
> *_ %ACC.sroa.4.012 = phi i64 [ 0, %for.body.lr.ph ], [
> %tmp.sroa.2.0.extract.shift, %for.body ]_*
>
> %i.011 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %for.body ]
>
> %arrayidx = getelementptr inbounds i16* %ary, i32 %i.011
>
> %0 = load i16* %arrayidx, align 2, !tbaa !1
>
> %add = add i32 %i.011, 8
>
> %arrayidx1 = getelementptr inbounds i16* %ary, i32 %add
>
> %1 = load i16* %arrayidx1, align 2, !tbaa !1
>
> %2 = tail call i64 @llvm.arc.ACC40.GUARD.MUL.SQ15.SQ15(i16 %0, i16
> %1) #1
>
> *_%L.sroa.0.0.insert.insert.i = or i64 %ACC.sroa.0.013, %ACC.sroa.4.012_*
>
> %3 = tail call i64 @llvm.arc.ADD.ACC40(i64
> %L.sroa.0.0.insert.insert.i, i64 %2) #1
>
> *_%tmp.sroa.2.0.extract.shift = and i64 %3, -4294967296_*
>
> %inc = add i32 %i.011, 1
>
> *_%phitmp9 = and i64 %3, 4294967295_*
>
> %cmp = icmp ult i32 %inc, %limit
>
> br i1 %cmp, label %for.body, label %for.cond.for.end_crit_edge
>
> The value of the OR is simply the PHI of %3 and 0. Nobody detects
> this and it generates pretty ugly code in a loop. Can you tell me
> what phase should handle this simple transform? That is, what phase
> does this kind of transformation belong in?
>
> Thanks
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140409/be10081f/attachment.html>