This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Improving GCC8 default option settings
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Martin Liška <mliska at suse dot cz>
- Cc: Markus Trippelsdorf <markus at trippelsdorf dot de>, Nikos Chantziaras <realnc at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, "Bin.Cheng" <amker dot cheng at gmail dot com>
- Date: Thu, 14 Sep 2017 12:24:37 +0200
- Subject: Re: RFC: Improving GCC8 default option settings
- Authentication-results: sourceware.org; auth=none
- References: <HE1PR0801MB2058CFEE6A9C43380337A83F83690@HE1PR0801MB2058.eurprd08.prod.outlook.com> <firstname.lastname@example.org> <CAFiYyc1q_6fT-=6rinozDzVseyE8wjOSs-T3pV6AEFjx3Xux3A@mail.gmail.com> <20170914100740.GB283@x4> <email@example.com>
On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška <firstname.lastname@example.org> 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 <email@example.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
>>>>> Other compilers enable more optimizations at -O2 (loop unrolling in LLVM
>>>>> 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.