On 09/14/2017 12:37 PM, Bin.Cheng wrote: > On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška <mli...@suse.cz> wrote: >>> On 09/14/2017 12:07 PM, Markus Trippelsdorf wrote: >>>> On 2017.09.14 at 11:57 +0200, Richard Biener wrote: >>>>> On Wed, Sep 13, 2017 at 6:11 PM, Nikos Chantziaras <rea...@gmail.com> >>>>> wrote: >>>>>> On 12/09/17 16:57, Wilco Dijkstra wrote: >>>>>>> >>>>>>> [...] As a result users are >>>>>>> required to enable several additional optimizations by hand to get good >>>>>>> code. >>>>>>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM >>>>>>> was >>>>>>> mentioned repeatedly) which GCC could/should do as well. >>>>>>> [...] >>>>>>> >>>>>>> I'd welcome discussion and other proposals for similar improvements. >>>>>> >>>>>> >>>>>> What's the status of graphite? It's been around for years. Isn't it >>>>>> mature >>>>>> enough to enable these: >>>>>> >>>>>> -floop-interchange -ftree-loop-distribution -floop-strip-mine >>>>>> -floop-block >>>>>> >>>>>> by default for -O2? (And I'm not even sure those are the complete set of >>>>>> graphite optimization flags, or just the "useful" ones.) >>>>> >>>>> It's not on by default at any optimization level. The main issue is the >>>>> lack of maintainance and a set of known common internal compiler errors >>>>> we hit. The other issue is that there's no benefit of turning those on >>>>> for >>>>> SPEC CPU benchmarking as far as I remember but quite a bit of extra >>>>> compile-time cost. >>>> >>>> Not to mention the numerous wrong-code bugs. IMHO graphite should >>>> deprecated as soon as possible. >>>> >>> >>> For wrong-code bugs we've got and I recently went through, I fully agree >>> with this >>> approach and I would do it for GCC 8. There are PRs where order of simple 2 >>> loops >>> is changed, causing wrong-code as there's a data dependence. >>> >>> Moreover, I know that Bin was thinking about selection whether to use >>> classical loop >>> optimizations or Graphite (depending on options provided). This would >>> simplify it ;) >> >> I don't think removing graphite is warranted, I still think it is the >> approach to use when >> handling non-perfect nests. > Hi, > IMHO, we should not be in a hurry to remove graphite, though we are > introducing some traditional transformations. It's a quite standalone > part in GCC and supports more transformations. Also as it gets more > attention, never know if somebody will find time to work on it.
Ok. I just wanted to express that from user's perspective I would not recommend it to use. Even if it improves some interesting (and for classical loop optimization hard) loop nests, it can still blow up on a quite simple data dependence in between loops. That said, it's quite risky to use it. Thanks, Martin > > Thanks, > bin >> >> Richard. >> >>> Martin
