[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