On Thu, Sep 14, 2017 at 3:08 PM, Markus Trippelsdorf <mar...@trippelsdorf.de> wrote: > 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.
But unfortunately there isn't a self-contained testcase for that. The comments hint at sth like int a[][]; p = &a[1][0]; for(;;) a[i][j] = ... p[i] = ... would get at it, that is, accessing memory via two-dim array and pointer. Richard. > -- > Markus
