On 2017.09.14 at 14:48 +0200, Richard Biener wrote: > On Thu, Sep 14, 2017 at 12:42 PM, Martin Liška <mli...@suse.cz> wrote: > > 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. > > We only have a single wrong-code bug in bugzilla with a testcase and I > just fixed it (well, > patch in testing). We do have plenty of ICEs, yes.
Even tramp3d-v4, which is cited in several graphite papers, gets miscompiled: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823. -- Markus
