[polly] speedup compile time for functions with no loops

[Sebastian Pop]

Hi,

I don't have a testcase under hand, and sending huge files over email
is not optimal,
so here is how to get plenty of interesting huge testcases: compile
the nightly test-suite
with clang -ftime-report and polly enabled.

Then grep for Polly in the compile log, I see things like this:

  21.3500 ( 48.2%)   0.0000 (  0.0%)  21.3500 ( 48.1%)  22.2737 (
42.3%)  Polly - Detect static control parts (SCoPs)

Note that I am still seeing huge compile time degradations with the patch
when compiling a lot of functions with loops,
although that's less often than without the patch ;-)

There is still room for improvement to cut down from that time,
maybe focusing scop detection on loop nests: i.e., run scop detection
on the loop info iterating over loops and not over basic blocks to discover
the interesting hot spots for polly.

Sebastian

On Thu, May 30, 2013 at 11:37 AM, Tobias Grosser <tobias at grosser.es> wrote:
> On 05/29/2013 09:58 AM, Sebastian Pop wrote:
>>
>> Hi,
>>
>> when compiling c++ code (or c code with a lot of functions), scop
>> detection
>> shows a huge overhead: probably 1/3 of the compile time is spent in scop
>> detection trying to find out maximal regions in functions with no loops.
>>
>> Here is a preliminary patch (does not fix the testsuite) that disables
>> scop
>> detection on functions with no loops:
>
>
> Hi Sebastian,
>
> I see where you are heading. Regarding the patch or the solution you
> propose:
>
> I dislike the idea of adding an option here, as the non-default case may
> become stale. On the other hand I understand that we really do not have any
> use case yet where a scop without a loop could be speed up significantly. So
> adding this heuristic really makes sense.
>
> In an optimal world, I would like to run the scop detection on everything
> just to ensure we do not regress on non-loop scops. However for this the
> overhead needs to be negligible. For now we can probably
> add the above patch, enable it by default and add an option that keeps
> the original functionality. As we have tests to cover this functionality
> the risk of the code getting stale is hopefully not as high.
>
> As Star Tan was accepted to his summer of code to work on exactly this
> issue, I would like him to investigate this closer. Do you happen to have
> test cases that show the above slowness? Could you point him to those test
> cases?
>
> Regarding the patch you propose and the one Star Tan sent. I would go for an
> option that explicitly disables loops, not not for a -polly-fast-detection.
> A generic option does not seem to make sense, as we want the detection to
> always be fast. ;-)
>
> If we agree on the above a patch along this lines is OK to commit.
>
> Cheers,
> Tobias
>
>
>
>> diff --git a/lib/Analysis/ScopDetection.cpp
>> b/lib/Analysis/ScopDetection.cpp
>> index ab323fd..ee2721d 100644
>> --- a/lib/Analysis/ScopDetection.cpp
>> +++ b/lib/Analysis/ScopDetection.cpp
>> @@ -785,9 +785,12 @@ void
>> ScopDetection::printInvalidLocations(llvm::Function &F) {
>>
>>   }
>>   bool ScopDetection::runOnFunction(llvm::Function &F) {
>> +  LI = &getAnalysisID<LoopInfo>(LoopInfo::getClassPassID());
>> +  if (LI->empty())
>> +    return false;
>> +
>>     AA = &getAnalysisID<AliasAnalysis>(AliasAnalysis::getClassPassID());
>>     SE =
>> &getAnalysisID<ScalarEvolution>(ScalarEvolution::getClassPassID());
>> -  LI = &getAnalysisID<LoopInfo>(LoopInfo::getClassPassID());
>>     RI = &getAnalysisID<RegionInfo>(RegionInfo::getClassPassID());
>>     Region *TopRegion = RI->getTopLevelRegion();
>>
>>
>> My question is how do you want to fix the testsuite? Do you want to remove
>> or
>> rewrite the files that check for patterns in functions with no loops, or
>> do you
>> want to add a flag to enable scop detection even with no loops in a
>> function?
>>
>> I would prefer the flag solution: it's the easiest way for me to fix
>> the testsuite.
>>
>> Thanks,
>> Sebastian
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> hosted by The Linux Foundation
>>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits



-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation