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 ;) Martin