[llvm-commits] [llvm] r154007 - /llvm/trunk/lib/Transforms/Scalar/LoopUnrollPass.cpp
Hongbin Zheng
etherzhhb at gmail.com
Wed Apr 4 05:11:56 PDT 2012
Hi tobi,
On Wed, Apr 4, 2012 at 8:10 PM, Tobias Grosser <tobias at grosser.es> wrote:
> 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?
Nope, i am going to do this :)
best regards
ether
>
> Tobi
More information about the llvm-commits
mailing list