From patchwork Fri Sep 16 19:02:36 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Senthil Kumar Selvaraj X-Patchwork-Id: 671081 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 3sbPp31kP4z9sC3 for ; Sat, 17 Sep 2016 05:03:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=QWL5/dFG; 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; q=dns; s= default; b=RUbuIXSF4X0aH55KZOBEytxzVamCU2EMea18lRZwkvc6BoIYH0ah+ y2a5qcdE1becobVHLMw3jnR/doRhY+wA0qYHV4Z/oUIax6BCnMdWRdbbOwUC/6Ld dEtO95B31FiGW7kqQGM6YzyKrj3LjOMdoCNz115CUlFBknA5B3c50M= 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; s= default; bh=E8pCI+vzM2eSqwVNri1bt/JwXoA=; b=QWL5/dFGy9oieHK7KK8T ss2BGDCO3CyAQis33byHZNv+qy0er6nR7eV7MU/f1ligKdXwvF5ZTRNBNFlmZ+Ma dV0AkR70dOm7RBb8LrbJl7UJSjdpqtuOfZG7ca/sNsKBsEYWHMwLbP/5A0AIJi+3 /512kSZO5E46q2IckUbPCpc= Received: (qmail 92314 invoked by alias); 16 Sep 2016 19:03:45 -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 91479 invoked by uid 89); 16 Sep 2016 19:03:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 spammy=sk:first_p, sk:FIRST_P, Hx-languages-length:2730 X-HELO: eusmtp01.atmel.com Received: from eusmtp01.atmel.com (HELO eusmtp01.atmel.com) (212.144.249.243) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Sep 2016 19:03:43 +0000 Received: from HNOCHT02.corp.atmel.com (10.145.133.41) by eusmtp01.atmel.com (10.145.145.31) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Sep 2016 21:03:33 +0200 Received: from jaguar.atmel.com (10.145.133.18) by HNOCHT02.corp.atmel.com (10.145.133.41) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 16 Sep 2016 21:03:38 +0200 User-agent: mu4e 0.9.17; emacs 24.5.1 From: Senthil Kumar Selvaraj To: Bernd Schmidt , gcc Patches Subject: [Patch, reload, tentative, PR 71627] Tweak conditions in find_valid_class_1 Date: Sat, 17 Sep 2016 00:32:36 +0530 Message-ID: <87lgyris6r.fsf@atmel.com> MIME-Version: 1.0 X-IsSubscribed: yes Hi, The below patch fixes what I think are a couple of problems with reload.c:find_valid_class_1. First, even if no regno is in_hard_reg_set_p, it goes ahead and considers rclass as valid. bad is set only if a regno is in the reg class *and* HARD_REGNO_MODE_OK is false - if both are false, bad isn't set and the reload gets a wrong rclass. If that happens to be the best one, this eventually leads to find_reg running out of registers to spill, because the chosen rclass won't have enough regs. Second, it expects every regno in rclass to be valid for mode i.e., if any regno fails HARD_REGNO_MODE_OK, it rejects the rclass. The comments in the original commit for find_valid_class_1 say atleast one regno is ok. This was updated to say "class which contains only registers" when in_hard_reg_set_p was introduced in place of just TEST_HARD_REG_BIT. Is it meant to really test all regs? For the avr target, all regs are 8 bits wide, and HARD_REGNO_MODE_OK returns false for odd regnos if mode != QImode. With the current code, it ignores a bunch of otherwise perfectly legal reg classes. To fix the first problem, the patch adds regno_in_rclass_mode to track whether there's atleast one regno in hard_reg_set_p. To fix the second problem, the patch sets bad initially, and resets it if HARD_REGNO_MODE_OK succeeded for a regno, thus breaking the loop. Of course, if both my points above are valid, we can do away with regno_in_rclass_mode, just bad would do. Does this make sense? I ran a reg test for the avr target with a slightly older version of this patch, it did not show any regressions. If this is the right fix, I'll make sure to run reg tests on x86_64 after backporting to a gcc version where that target used reload. Regards Senthil Index: reload.c =================================================================== --- reload.c (revision 240185) +++ reload.c (working copy) @@ -714,17 +714,22 @@ for (rclass = 1; rclass < N_REG_CLASSES; rclass++) { - int bad = 0; - for (regno = 0; regno < FIRST_PSEUDO_REGISTER && !bad; regno++) - { - if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno) - && !HARD_REGNO_MODE_OK (regno, mode)) - bad = 1; - } - - if (bad) - continue; + int bad = 1; + int regno_in_rclass_mode = 0; + for (regno = 0; regno < FIRST_PSEUDO_REGISTER && bad; regno++) + { + if (in_hard_reg_set_p (reg_class_contents[rclass], mode, regno)) + { + regno_in_rclass_mode = 1; + if (HARD_REGNO_MODE_OK (regno, mode)) + bad = 0; + } + } + + if (bad || !regno_in_rclass_mode) + continue; + cost = register_move_cost (outer, (enum reg_class) rclass, dest_class); if ((reg_class_size[rclass] > best_size