[llvm-commits] [llvm] r154007 - /llvm/trunk/lib/Transforms/Scalar/LoopUnrollPass.cpp

Tobias Grosser tobias at grosser.es
Wed Apr 4 05:10:48 PDT 2012


On 04/04/2012 02:07 PM, Hongbin Zheng wrote:
> Hi tobi,
>
> It looks like a trivial typo [1],  as you can find the comment of "Threshold":
>
>    // Determine the current unrolling threshold.  While this is normally set
>    // from UnrollThreshold, it is overridden to a smaller value if the current
>    // function is marked as optimize-for-size, and the unroll threshold was
>    // not user specified.
>    unsigned Threshold = CurrentThreshold;
>    if (!UserThreshold&&
>        Header->getParent()->hasFnAttr(Attribute::OptimizeForSize))
>      Threshold = OptSizeUnrollThreshold;
>
> The "Threshold" is overridden by the the value of
> "OptSizeUnrollThreshold" if the function requires to be optimized for
> size. Hence, when we are reducing the unroll count of the loop to meet
> the threshold constraint, the original code reduce the unroll count
> according the variable "CurrentThreshold", instead of "Threshold",
> which may be adjusted by the function attribute.
>
> The original code:
>        if (TripCount) {
>          // Reduce unroll count to be modulo of TripCount for partial unrolling
>          Count = CurrentThreshold / LoopSize;
> <--------------------------should use Threshold
>          while (Count != 0&&  TripCount%Count != 0)

Sure. But maybe still worth adding a test case that stops this bug to be 
reintroduced in the next restructuring. Would it be too hard to create one?

Tobi



More information about the llvm-commits mailing list