[LLVMdev] Is this a bug with loop unrolling and TargetTransformInfo ?
Hal Finkel
hfinkel at anl.gov
Wed Feb 4 12:48:36 PST 2015
----- Original Message -----
> From: "Tom Stellard" <tom at stellard.net>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: llvmdev at cs.uiuc.edu
> Sent: Wednesday, February 4, 2015 2:43:16 PM
> Subject: Re: [LLVMdev] Is this a bug with loop unrolling and TargetTransformInfo ?
>
> On Wed, Feb 04, 2015 at 02:05:11PM -0600, Hal Finkel wrote:
> > ----- Original Message -----
> > > From: "Tom Stellard" <tom at stellard.net>
> > > To: llvmdev at cs.uiuc.edu
> > > Sent: Wednesday, February 4, 2015 1:45:26 PM
> > > Subject: [LLVMdev] Is this a bug with loop unrolling and
> > > TargetTransformInfo ?
> > >
> > > Hi,
> > >
> > > I ran into this issue recently and wanted to know if it was a bug
> > > or
> > > expected behavior.
> > >
> > > In the R600 backend's TargetTransformInfo implementation, we were
> > > setting
> > > UnrollingPreferences::Count = UINT_MAX. This was a mistake as we
> > > should have been
> > > setting UnrollingPreferences::MaxCount instead. However, as a
> > > result
> > > of setting
> > > Count to UINT_MAX, this loop would be unrolled 15 times:
> >
> > A bug regardless? Where did 15 come from?
> >
>
> It's the value computed by this loop on line 453 of the
> LoopUnrolPass.
> Inputs are:
>
> Count = 4294967295
> PartialThreshold = 150
> UnrolledSize = 34359738362
>
> // Reduce unroll count to be the largest power-of-two factor of
> // the original count which satisfies the threshold limit.
> while (Count != 0 && UnrolledSize > PartialThreshold) {
> Count >>= 1;
> UnrolledSize = (LoopSize-2) * Count + 2;
> }
>
> I think the bug here may actually be in
> LoopUnroll::selectUnrollCount(). It looks like it ends up returning
> UP.Count
> in some cases when it is larger than TripCount.
That does indeed seem like a bug, or something that should assert (if Count is too large).
-Hal
>
> -Tom
> >
> > >
> > > if (b + 4 > a) {
> > > for (int i = 0; i < 4; i++, b++) {
> > > if (b + 1 <= a)
> > > *(dst + c + b) = 0;
> > > else
> > > break;
> > > }
> > > }
> > >
> > > Is this the expected behavior? Is the loop unroll pass supposed
> > > to
> > > use the
> > > value of UnrollingPreferecnes::Count even if it is clearly wrong?
> > >
> > > I have an LLVM IR test case for this issue attached to this
> > > patch:
> > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20150202/257276.html
> > >
> > > -Tom
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> > >
> >
> > --
> > Hal Finkel
> > Assistant Computational Scientist
> > Leadership Computing Facility
> > Argonne National Laboratory
>
--
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev
mailing list