On 1 April 2016 at 18:19, Jeff Law <l...@redhat.com> wrote: > On 04/01/2016 07:26 AM, Christophe Lyon wrote: >> >> On 1 April 2016 at 15:12, Kyrill Tkachov <kyrylo.tkac...@foss.arm.com> >> wrote: >>> >>> Hi Christophe, Andrey, >>> >>> >>> On 01/04/16 14:09, Christophe Lyon wrote: >>>> >>>> >>>> On 1 April 2016 at 10:54, Andrey Belevantsev <a...@ispras.ru> wrote: >>>>> >>>>> >>>>> Hi Christophe, >>>>> >>>>> >>>>> On 01.04.2016 10:33, Christophe Lyon wrote: >>>>>> >>>>>> >>>>>> On 31 March 2016 at 16:43, Andrey Belevantsev <a...@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. >>> >> You are right: I've just checked that backporting your patch r230088 does >> fix the problems in the gcc-5 branch. >> >> Can I commit it ? I guess the question is for Jakub? > > Yes, you can commit it to the branch. >
OK, done at r234680 Christophe > jeff >
