[llvm-commits] [llvm] r69631 - /llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp

[Evan Cheng]

On Apr 20, 2009, at 3:41 PM, Dale Johannesen wrote:

>
> On Apr 20, 2009, at 3:25 PMPDT, Evan Cheng wrote:
>> On Apr 20, 2009, at 3:19 PM, Dale Johannesen wrote:
>>> Author: johannes
>>> Date: Mon Apr 20 17:19:33 2009
>>> New Revision: 69631
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=69631&view=rev
>>> Log:
>>> Adjust loop size estimate for full unrolling;
>>> GEP's don't usually become instructions.
>>
>> Well... That's not entirely true. Each GEP can also become a several
>> instructions. Is there a test case to demonstrate the merit of this
>> change?
>>
>> Evan
>
> It causes several loops in openssl(aes) to become completely unrolled,
> recovering 1/3 to 1/4 of the difference between llvm-gcc and gcc.
> All this is used for is determining whether to completely unroll
> loops, so it won't matter often.  But I have no problem doing this
> some other way, e.g. increasing the threshold, if you prefer.  Why
> don't we see how it does overnight?

Have you had a chance to run it through some large tests, e.g. SPEC? I  
do expect this need to be revisited. Still, a test case is nice  
otherwise I have no clue what this really change.

>
>
>> How about changing it to what InlineCost.cpp does?
>>
>>      } else if (const GetElementPtrInst *GEPI =
>>                 dyn_cast<GetElementPtrInst>(II)) {
>>        // If a GEP has all constant indices, it will probably be
>> folded with
>>        // a load/store.
>>        bool AllConstant = true;
>>        for (unsigned i = 1, e = GEPI->getNumOperands(); i != e; ++i)
>>          if (!isa<ConstantInt>(GEPI->getOperand(i))) {
>>            AllConstant = false;
>>            break;
>>          }
>>        if (AllConstant) continue;
>
> The subscripts involved are not constant (they're based off the
> induction variable, as you would expect in a loop), so that won't  
> work.

Ok.  I am actually more or less ok with the change. If this pessmize  
some code (which it probably) will, the fix is to teach some later  
passes to recover gracefully (easier said then done).

Evan

>
>
>>> Modified:
>>>  llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp
>>>
>>> Modified: llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp
>>> URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp?rev=69631&r1=69630&r2=69631&view=diff
>>>
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> =
>>> = 
>>> ====================================================================
>>> --- llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp (original)
>>> +++ llvm/trunk/lib/Transforms/Scalar/LoopUnroll.cpp Mon Apr 20
>>> 17:19:33 2009
>>> @@ -89,6 +89,8 @@
>>>       // Ignore instructions only used by the loop terminator.
>>>     } else if (isa<DbgInfoIntrinsic>(I)) {
>>>       // Ignore debug instructions
>>> +      } else if (isa<GetElementPtrInst>(I) && I->hasOneUse()) {
>>> +        // Ignore GEP as they generally are subsumed into a load or
>>> store.
>>>     } else if (isa<CallInst>(I)) {
>>>       // Estimate size overhead introduced by call instructions
>>> which
>>>       // is higher than other instructions. Here 3 and 10 are magic
>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits