public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
To: Christophe Lyon <christophe.lyon@linaro.org>,
	 Andrey Belevantsev <abel@ispras.ru>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	 Alexander Monakov <amonakov@ispras.ru>
Subject: Re: Various selective scheduling fixes
Date: Fri, 01 Apr 2016 13:12:00 -0000	[thread overview]
Message-ID: <56FE73AB.8020500@foss.arm.com> (raw)
In-Reply-To: <CAKdteObRyOg7wh870mKhHJKtoOz6Loa6AV_ZavL1NDF_dTXz5Q@mail.gmail.com>

Hi Christophe, Andrey,

On 01/04/16 14:09, Christophe Lyon wrote:
> On 1 April 2016 at 10:54, Andrey Belevantsev <abel@ispras.ru> wrote:
>> Hi Christophe,
>>
>>
>> On 01.04.2016 10:33, Christophe Lyon wrote:
>>> On 31 March 2016 at 16:43, Andrey Belevantsev <abel@ispras.ru> wrote:
>>>> Hello,
>>>>
>>>> On 14.03.2016 12:10, Andrey Belevantsev wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> In this thread I will be posting the patches for the fixed selective
>>>>> scheduling PRs (except the one that was already kindly checked in by
>>>>> Jeff).
>>>>>   The patches were tested both on x86-64 and ia64 with the following
>>>>> combination: 1) the usual bootstrap/regtest, which only utilizes
>>>>> sel-sched
>>>>> on its own tests, made by default to run on arm/ppc/x86-64/ia64; 2) the
>>>>> bootstrap/regtest with the second scheduler forced to sel-sched; 3) both
>>>>> schedulers forced to sel-sched.  In all cases everything seemed to be
>>>>> fine.
>>>>>
>>>>> Three of the PRs are regressions, the other two showed different errors
>>>>> across the variety of releases tested by submitters;  I think all of
>>>>> them
>>>>> are appropriate at this stage -- they do not touch anything outside of
>>>>> selective scheduling except the first patch where a piece of code from
>>>>> sched-deps.c needs to be refactored into a function to be called from
>>>>> sel-sched.c.
>>>>
>>>>
>>>> I've backported all regression PRs to gcc-5-branch after testing there
>>>> again
>>>> with selective scheduling force enabled: PRs 64411, 66660, 69032, 69102.
>>>> The first one was not marked as a regression as such but the test for PR
>>>> 70292, which is duplicate, works for me on gcc 5.1 thus making it a
>>>> regression, too.
>>>>
>>> Hi,
>>>
>>> The backport for pr69102 shows that the new testcase fails to compile
>>> (ICE)
>>> when GCC is configured as:
>>>
>>> --target=arm-none-linux-gnueabihf --with-float=hard --with-mode=arm
>>> --with-cpu=cortex-a15 --with-fpu=neon-vfpv4
>>>
>>>
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.c-torture/compile/pr69102.c:
>>> In function 'foo':
>>>
>>> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/gcc.c-torture/compile/pr69102.c:21:1:
>>> internal compiler error: Segmentation fault
>>> 0xa64d15 crash_signal
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/toplev.c:383
>>> 0xfa41d7 autopref_multipass_dfa_lookahead_guard(rtx_insn*, int)
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:5752
>>> 0xa31cd2 invoke_dfa_lookahead_guard
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:4212
>>> 0xa31cd2 find_best_expr
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:4415
>>> 0xa343fb fill_insns
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:5570
>>> 0xa343fb schedule_on_fences
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:7395
>>> 0xa36010 sel_sched_region_2
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:7533
>>> 0xa36f2a sel_sched_region_1
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:7575
>>> 0xa36f2a sel_sched_region(int)
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:7676
>>> 0xa37589 run_selective_scheduling()
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sel-sched.c:7752
>>> 0xa14aed rest_of_handle_sched2
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3647
>>> 0xa14aed execute
>>>          /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3791
>>>
>>> See
>>> http://people.linaro.org/~christophe.lyon/cross-validation/gcc/gcc-5-branch/234625/arm-none-linux-gnueabihf/diff-gcc-rh60-arm-none-linux-gnueabihf-arm-cortex-a15-neon-vfpv4.txt
>>>
>>> Can you have a look?
>>
>> That's because A15 is the only place which enables
>> autopref_multipass_dfa_lookahead_guard as the DFA lookahead guard hook. But
>> autoprefetch modeling doesn't work for selective scheduling, it uses haifa
>> structures that are not kept up to date during sel-sched.  So this is not
>> supposed to work as soon as the param value for prefetcher lookahead depth
>> is positive.
>>
>> The following patch works for me.  Could you check it with your testing? If
>> it works fine for you, I would install the patch both for trunk and gcc-5.
>> It would be great to force sel-sched to be enabled, too.  I could do that
>> but I don't have the hardware or cross-arm target tools at the moment.
>>
>>          * haifa-sched.c (autopref_multipass_dfa_lookahead_guard): Disable
>> for selective scheduler.
>>
> It does work for me, it also fixes the other ICE I reported (on pr69307).
>
> But note that both tests pass on trunk.

This looks to me like PR rtl-optimization/68236 which I fixed on trunk.

Kyrill

> Christophe
>
>
>> Best,
>> Andrey
>>
>>
>>> Christophe
>>>
>>>> Andrey
>>>>
>>>>> Andrey
>>>>
>>>>

  reply	other threads:[~2016-04-01 13:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-14  9:11 Andrey Belevantsev
2016-03-14  9:22 ` [01/05] Fix PR 64411 Andrey Belevantsev
2016-03-14 16:23   ` Alexander Monakov
2016-03-14 16:45     ` Bernd Schmidt
2016-03-15 15:43       ` Andrey Belevantsev
2016-03-14  9:32 ` [02/05] Fix PR 63384 Andrey Belevantsev
2016-03-14 17:13   ` Alexander Monakov
2016-03-15 17:30   ` Marek Polacek
2016-03-15 17:44     ` Alexander Monakov
2016-03-15 18:00       ` Andrey Belevantsev
2016-03-15 18:12         ` Alexander Monakov
2016-03-14  9:36 ` [03/05] Fix PR 66660 Andrey Belevantsev
2016-03-14 17:37   ` Alexander Monakov
2016-03-14  9:40 ` [04/05] Fix PR 69032 Andrey Belevantsev
2016-03-14 18:15   ` Alexander Monakov
2016-03-14  9:53 ` [05/05] Fix PR 69102 Andrey Belevantsev
2016-03-15 15:55   ` Andrey Belevantsev
2016-03-17 16:39     ` Jeff Law
2016-03-31 14:55 ` Various selective scheduling fixes Andrey Belevantsev
2016-04-01  7:33   ` Christophe Lyon
2016-04-01  8:55     ` Andrey Belevantsev
2016-04-01 13:09       ` Christophe Lyon
2016-04-01 13:12         ` Kyrill Tkachov [this message]
2016-04-01 13:26           ` Christophe Lyon
2016-04-01 16:19             ` Jeff Law
2016-04-01 20:08               ` Christophe Lyon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56FE73AB.8020500@foss.arm.com \
    --to=kyrylo.tkachov@foss.arm.com \
    --cc=abel@ispras.ru \
    --cc=amonakov@ispras.ru \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).