RFC: Improving GCC8 default option settings

[Bin.Cheng]

On Thu, Sep 14, 2017 at 11:24 AM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Sep 14, 2017 at 12:18 PM, Martin Liška <mliska@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 <realnc@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.

Thanks,
bin
>
> Richard.
>
>> Martin