From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2412 invoked by alias); 3 Dec 2015 14:25:32 -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 2401 invoked by uid 89); 3 Dec 2015 14:25:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qg0-f49.google.com Received: from mail-qg0-f49.google.com (HELO mail-qg0-f49.google.com) (209.85.192.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 03 Dec 2015 14:25:30 +0000 Received: by qgea14 with SMTP id a14so61190052qge.0 for ; Thu, 03 Dec 2015 06:25:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CfGuePYMdfFtMQtQ8bD+5EBTpCqZcYGY3AYCMfOneDM=; b=jq65e4oDu9SODtJx78PAQhPPUkex7OR9T15xE7/RQeVCRawX4LP+mexSVYCMr07Tqr kom/0rPZUcGnNNDK0E/YrnEiuZcQO9JPsDJ55zdxSv/ggQuiTSAcfWoCjDdjOs73b1wH kuxM0FXJvK04axskmS19kVJvaYtHkrCChtfeMBEtFaH8R3ldQt1cDpJkdbHnE/3aYb6p nWyHANAPOkwOC4Nw3DAU7j+Os5x6J0IB7gNr/7BXa0xeaWLP4H+sBT1Sx/9SQmgbMQ1+ 25uSsQXUv5EXuttpPkQPZJvD+3JAFypSV8LVzGPobCAfuPskOZ5oYuWq69b1yFwVhX2/ 7sRQ== X-Gm-Message-State: ALoCoQlKgnCxCtbPFwEYTlNrXhOoLPuEizFJHeB06Jjl7kVTQsRWd36bJelo0bpUmPRflLXygwxq MIME-Version: 1.0 X-Received: by 10.140.152.150 with SMTP id 144mr12357642qhy.8.1449152728679; Thu, 03 Dec 2015 06:25:28 -0800 (PST) Received: by 10.140.82.137 with HTTP; Thu, 3 Dec 2015 06:25:28 -0800 (PST) In-Reply-To: <56583DFF.50303@foss.arm.com> References: <561FB1B4.3060103@arm.com> <5620D6F3.102@foss.arm.com> <5621017F.5030604@arm.com> <565824F1.4030404@arm.com> <56583DFF.50303@foss.arm.com> Date: Thu, 03 Dec 2015 14:25:00 -0000 Message-ID: Subject: Re: [PR67383][ARM][4.9]Backport of "Allow any register for DImode values in Thumb2" From: Christophe Lyon To: Ramana Radhakrishnan Cc: Renlin Li , "gcc-patches@gcc.gnu.org" , Vladimir Makarov , Kyrill Tkachov Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg00443.txt.bz2 On 27 November 2015 at 12:26, Ramana Radhakrishnan wrote: > > > On 27/11/15 09:40, Renlin Li wrote: >> Hi Ramana, >> >> On 16/10/15 14:54, Renlin Li wrote: >>> >>> >>>> The command line implies we remove r7 (frame pointer in Thumb2 - historical accident, fno-omit-frame-pointer), r9 (ffixed-r9), r10 (-mpic-register) which >>>> leaves us with: >>>> >>>> * r0, r1 >>>> * r2, r3 >>>> * r4, r5 >>>> >>>> as the only free registers available for DImode values for the whole compilation. >>>> >>>> We then have r0, r1 and r2 live across the insn which means that there are no free registers to handle DImode values >>>> under the constraints provided unless LRA / reload can spill the argument registers which it doesn't seem to be able to do >>>> in this particular testcase. Vlad, is that correct ? >>> According to the logic, conflict hard register are excluded from spill candidate. That's why, in this case, r0, r1, r2 cannot be used. >> >> >> In the test case, there are code structure like this. >> >> >> uint64_t callee (int a, int b, int c, int d); >> uint64_t caller (int a, int b, int c, int d) >> { >> uint64_t res; >> /* >> single BB contains complicated data processing which requires register pair >> */ >> >> res = callee (tmp, b ,c, d); >> return res; >> } >> >> CES pass in this case will extend the hard register live range across the whole BB until the callee. In this case, r1, r2, r3 are excluded from allocatable registers. >> >> There are places in CES which prevents extending the hard register's live range, for example for hard register which fullfil small_register_classes_for_mode_p(), class_likely_spilled_p(). However, argument registers belong to neither of them. >> >> I tried to stop CES from extending argument registers live range. However, later, scheduler jumps in and re-orders the instruction to reduce the pseudo register pressure, which in effect extend the argument register live again. > > Thanks for digging further and trying to figure out what the solution was. I can't think of a less risky fix than what you have proposed, thus Ok if no regressions. > > Hi, I have noticed regressions after this commit to the 4.9 branch: Passed now fails [PASS => FAIL]: gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) Pass disappears [PASS => ]: gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto -fno-use-linker-plugin -flto-partition=none gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects Fail appears [ => FAIL]: gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) gcc.c-torture/compile/pr34856.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 (internal compiler error) gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) gcc.c-torture/execute/scal-to-vec1.c compilation, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects (internal compiler error) See the red links in http://people.linaro.org/~christophe.lyon/cross-validation/gcc/gcc-4_9-branch/231177/report-build-info.html Christophe. > regards > Ramana > > > > > >> >> Regards, >> >> Renlin Li >> >> >>