From patchwork Tue Nov 10 13:30:57 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Wilco Dijkstra X-Patchwork-Id: 542296 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 046AB141414 for ; Wed, 11 Nov 2015 00:31:16 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=VAAWM3mq; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=ZhWRd3CcAFC+WxcF mBPGtaYyiHMNC7LxB+nCSvaD61BIFBfWD9sPCMyV6IUbu/2+DW8SB+AfdqaNvQs1 B3WBVxgHLdlnoP0XQ8lYf7BRd6CVq8nQ66M7yV67bKmbf6N5rL6SGBg8y6Z4pS3K 3Bv9lbWSFGnDwRPob5uRvsRpeqM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=8l3WwP5D8cllB38F8KOQQL bIPhM=; b=VAAWM3mq6kRPMHEjQBLT02B5geTd4PUnmRIk5qvVuJn66A30ykle48 2OuRQ071zz95ky5TqnhxCjy3WEYrrQjuMAQaBXjo8muqV9r+GA4f9wpKS0sygHka ffibgtP41S8slz5eXjReuEIy5Dfoa3np3DSDDnRvfELIYIkRtTz40= Received: (qmail 56760 invoked by alias); 10 Nov 2015 13:31:09 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 56749 invoked by uid 89); 10 Nov 2015 13:31:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL, BAYES_00, SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 10 Nov 2015 13:31:06 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-11-uA9K5E2KSGKqM1wpn3DW0A-1; Tue, 10 Nov 2015 13:31:00 +0000 Received: from E107166VM ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2015 13:30:59 +0000 From: "Wilco Dijkstra" To: Subject: [PATCH] Fix IRA register preferencing Date: Tue, 10 Nov 2015 13:30:57 -0000 Message-ID: <001501d11bbc$085031d0$18f09570$@arm.com> MIME-Version: 1.0 X-MC-Unique: uA9K5E2KSGKqM1wpn3DW0A-1 Ping of https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00829.html: This fixes a bug in register preferencing. When live range splitting creates a new register from another, it copies most fields except for the register preferences. The preference GENERAL_REGS is used as reg_pref[i].prefclass is initialized with GENERAL_REGS in allocate_reg_info () and resize_reg_info (). This initialization value is not innocuous like the comment suggests - if a new register has a non-integer mode, it is forced to prefer GENERAL_REGS. This changes the register costs in pass 2 so that they are incorrect. As a result the liverange is either spilled or allocated to an integer register: void g(double); void f(double x) {   if (x == 0)     return;   g (x);   g (x); } f:         fcmp    d0, #0.0         bne     .L6         ret .L6:         stp     x19, x30, [sp, -16]!         fmov    x19, d0         bl      g         fmov    d0, x19         ldp     x19, x30, [sp], 16         b       g With the fix it uses a floating point register as expected. Given a similar issue in https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02253.html, would it not be better to change the initialization values of reg_pref to illegal register classes so this kind of issue can be trivially found with an assert? Also would it not be a good idea to have a single register copy function that ensures all data is copied? ChangeLog: 2014-12-09  Wilco Dijkstra  wdijkstr@arm.com         * gcc/ira-emit.c (ira_create_new_reg): Copy preference classes. --- gcc/ira-emit.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/gcc/ira-emit.c b/gcc/ira-emit.c index d246b7f..d736836 100644 --- a/gcc/ira-emit.c +++ b/gcc/ira-emit.c @@ -348,6 +348,7 @@ rtx ira_create_new_reg (rtx original_reg) {    rtx new_reg; +  int original_regno = REGNO (original_reg);    new_reg = gen_reg_rtx (GET_MODE (original_reg));    ORIGINAL_REGNO (new_reg) = ORIGINAL_REGNO (original_reg); @@ -356,8 +357,16 @@ ira_create_new_reg (rtx original_reg)    REG_ATTRS (new_reg) = REG_ATTRS (original_reg);    if (internal_flag_ira_verbose > 3 && ira_dump_file != NULL)      fprintf (ira_dump_file, "      Creating newreg=%i from oldreg=%i\n", -            REGNO (new_reg), REGNO (original_reg)); +            REGNO (new_reg), original_regno);    ira_expand_reg_equiv (); + +  /* Copy the preference classes to new_reg.  */ +  resize_reg_info (); +  setup_reg_classes (REGNO (new_reg), +                   reg_preferred_class (original_regno), +                   reg_alternate_class (original_regno), +                   reg_allocno_class (original_regno)); +    return new_reg; }