From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124755 invoked by alias); 16 Oct 2019 15:41:55 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 124747 invoked by uid 89); 16 Oct 2019 15:41:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:4cd188a, H*f:sk:223d590, H*f:QSZcJoqiOjyM, H*f:CAJA7tRYRtATabn X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Oct 2019 15:41:54 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 347E0142F; Wed, 16 Oct 2019 08:41:52 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9DB2A3F68E; Wed, 16 Oct 2019 08:41:50 -0700 (PDT) Subject: Re: [PATCH][ARM] Switch to default sched pressure algorithm To: Wilco Dijkstra , Christophe Lyon , Ramana Radhakrishnan Cc: Ramana Radhakrishnan , GCC Patches , nd , Kyrylo Tkachov References: <223d5901-d9c4-4217-1242-352c3c36ed4d@foss.arm.com> <4cd188af-faad-697d-ed59-fe29fc00ce1c@arm.com> From: "Richard Earnshaw (lists)" Message-ID: <0bc2d50b-6061-4ced-e70d-a4a4615363e0@arm.com> Date: Wed, 16 Oct 2019 15:43:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-10/txt/msg01204.txt.bz2 On 16/10/2019 13:13, Wilco Dijkstra wrote: > Hi Christophe, > >> I've noticed that your patch caused a regression: >> FAIL: gcc.dg/tree-prof/pr77698.c scan-rtl-dump-times alignments >> "internal loop alignment added" 1 > > That's just a testism - it only tests for loop alignment and doesn't > consider the possibility of the loop being jumped into like this: > > .L17: >         adds    r0, r0, #1 >         b       .L27 > .L6: >         ldr     r4, [r2, #12] >         adds    r0, r0, #4 >         ldr     lr, [r1] >         str     lr, [r3, r4, lsl #2] >         ldr     r4, [r2, #12] >         ldr     lr, [r1] >         str     lr, [r3, r4, lsl #2] >         ldr     r4, [r2, #12] >         ldr     lr, [r1] >         str     lr, [r3, r4, lsl #2] > .L27: >         ldr     r4, [r2, #12] >         cmp     ip, r0 >         ldr     lr, [r1] >         str     lr, [r3, r4, lsl #2] >         bne     .L6 >         pop     {r4, pc} > > It seems minor changes in scheduling allows blocks to be commoned or not. > The underlying issue is that commoning like this should not be allowed on blocks > with different profile stats - particularly on loops where it inhibits scheduling of > the loop itself. > > Cheers, > Wilco > So what's your proposed solution? Leaving the test failing is not an option.