[polly] reorganize scop detection for faster compiles

Sebastian Pop spop at codeaurora.org
Mon Jun 3 09:13:23 PDT 2013


Tobias Grosser wrote:
> On 06/01/2013 09:31 PM, Sebastian Pop wrote:
> >Hi Tobi,
> >
> >Here are two patches that reorganize scop detection filters: the idea behind these
> >patches is to run the lightweight passes accessing the CFG and LoopInfo before
> >starting iterating over instructions in basic blocks.
> >
> >With these and previous patches, we still have room for improvement: here is
> >what I still see in one of the files:
> >
> >Ok to commit?
> 
> 
> I don't think they will hurt correctness wise.
> 

So can I take this as an ok to commit? ;-)

> However, if you see compile time improvements with these patches, it
> would be nice to know on which benchmarks you see how much
> improvements. Also, do you see any compile-time regressions?

I was compiling a big chunk of the Android codebase.

> I can see that the patches may reduce compile time for cases where
> the CFG commonly breaks the scops. On the other side, in case the
> CFGs are perfectly well structured, this may actually have a
> negative effect. I tend to agree that the first one may be more
> common, but it would be nice to back this up this intuition with
> some data.

Overall, with all my changes, I see the compile time of Polly dropping by 8x on
that benchmark.  Most of the remaining time is spent in scop detection as I
mentioned below, and I will be working on reducing that compile time overhead.

IMNSHO, scop detection should really be less expensive than polyhedral opts ;-)

> 
> > 285.8400 ( 69.2%)   2.1700 ( 44.7%)  288.0100 ( 68.9%)  295.9582 (
> 67.8%)  Polly - Detect static control parts (SCoPs)
> 
> Interesting. Do you happen to have a test case for this .ll file,
> which you could create a bug report for?

I don't know which parts of my benchmark are proprietary or open source, so I
wouldn't be able to extract a testcase to share.  As I mentioned in another
email, you can get the same kind of bad behavior in scop detection by looking at
other C++ code (dealII) and use -g.  I have an idea why adding -g takes longer,
so let me write you another email to explain my intuition.

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



More information about the llvm-commits mailing list