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.

Richard.

> Thanks,
> Martin
>
>>
>> Thanks,
>> bin
>>>
>>> Richard.
>>>
>>>> Martin
>

Reply via email to