This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Improving GCC8 default option settings


On Thu, Sep 14, 2017 at 3:08 PM, Markus Trippelsdorf
<markus@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 <mliska@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.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.
>> >
>> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]