From patchwork Wed Sep 28 22:38:49 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 116864 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]) by ozlabs.org (Postfix) with SMTP id CCBBBB6F91 for ; Thu, 29 Sep 2011 08:42:55 +1000 (EST) Received: (qmail 7568 invoked by alias); 28 Sep 2011 22:42:53 -0000 Received: (qmail 7560 invoked by uid 22791); 28 Sep 2011 22:42:53 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 28 Sep 2011 22:42:38 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id BAD7ACB021F; Thu, 29 Sep 2011 00:42:38 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ldp06RjwAjmA; Thu, 29 Sep 2011 00:42:28 +0200 (CEST) Received: from [192.168.1.2] (bon31-9-83-155-120-49.fbx.proxad.net [83.155.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 2049ACB01F0; Thu, 29 Sep 2011 00:42:28 +0200 (CEST) From: Eric Botcazou To: David Miller Subject: Re: [PATCH] Add explicit VIS intrinsics for addition and subtraction. Date: Thu, 29 Sep 2011 00:38:49 +0200 User-Agent: KMail/1.9.9 Cc: gcc-patches@gcc.gnu.org, Vladimir Makarov References: <20110927.000118.1421173401433924103.davem@davemloft.net> <201109271004.35397.ebotcazou@adacore.com> <20110927.041525.1949006323790613583.davem@davemloft.net> In-Reply-To: <20110927.041525.1949006323790613583.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <201109290038.49451.ebotcazou@adacore.com> 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 [Vlad, if you have a few minutes, would you mind having a look at the couple of questions at the end of the message? Thanks in advance]. > No problem. Here are the results of the investigation. Pseudo 116 needs to be assigned a hard register. It is used mostly in vector instructions so we would like it to be assigned a FP reg, but it is initialized in insn 2: (insn 2 5 3 2 (set (reg/v:V4HI 116 [ a ]) (reg:V4HI 24 %i0 [ a ])) combined-1.c:7 93 {*movdf_insn_sp32_v9} (expr_list:REG_DEAD (reg:V4HI 24 %i0 [ a ]) (nil))) so it ends up being assigned the (integer) argument register %i0 instead. It used to be assigned a FP reg as expected with the GCC 4.6.x series. The register class preference discovery is OK: r116: preferred EXTRA_FP_REGS, alternative GENERAL_OR_EXTRA_FP_REGS, allocno GENERAL_OR_EXTRA_FP_REGS a2 (r116,l0) best EXTRA_FP_REGS, allocno GENERAL_OR_EXTRA_FP_REGS i.e. EXTRA_FP_REGS is "preferred"/"best". Then it seems that this preference is dropped and only the class of the allocno, GENERAL_OR_EXTRA_FP_REGS, is handed down to the coloring stage. By contrast, in the GCC 4.6 series, the cover_class of the allocno is EXTRA_FP_REGS. The initial cost for %i0 is twice as high (24000) as the cost of FP regs. But then it is reduced by 12000 when process_bb_node_for_hard_reg_moves sees insn 2 above and then again by 12000 when process_regs_for_copy sees the same insn. So, in the end, %i0 is given cost 0 and thus beats every other register. This doesn't happen in the GCC 4.6 series because %i0 isn't in the cover_class. This is at -O1. At -O2, there is an extra pass at the discovery stage and it sets the class of the allocno to EXTRA_FP_REGS, like with the GCC 4.6 series, so a simple workaround is Finally the couple of questions: 1. Is it expected that the register class preference be dropped at -O1? 2. Is it expected that a single insn be processed by 2 different mechanisms that independently halve the initial cost of a hard register? Index: gcc.target/sparc/combined-1.c =================================================================== --- gcc.target/sparc/combined-1.c (revision 179316) +++ gcc.target/sparc/combined-1.c (working copy) @@ -1,5 +1,5 @@ /* { dg-do compile } */ -/* { dg-options "-O -mcpu=ultrasparc -mvis" } */ +/* { dg-options "-O2 -mcpu=ultrasparc -mvis" } */ typedef short vec16 __attribute__((vector_size(8))); typedef int vec32 __attribute__((vector_size(8)));