From patchwork Wed Jun 13 18:58:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dimitar Dimitrov X-Patchwork-Id: 929047 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-479653-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=dinux.eu Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="UwAHg+MU"; dkim-atps=neutral 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 415bf53R7Hz9s19 for ; Thu, 14 Jun 2018 04:59:41 +1000 (AEST) 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:cc:subject:date:message-id:in-reply-to:references; q=dns; s= default; b=kTu7steWr5Jjv2qhe2PjJAnwk6vQCrR42pNPGdcyUVFVxosmZBNtj 7ElVq8c6Afh0GbyY1nQHvf+GUl8cWnXnDs7bIYiHEpLJvltuj8E4du+Z7qMSrUP/ uSRNGSrdEGojZCg76mzacQJMhuZB4lkdDCYNW2QB13x0N1sCCQgRMQ= 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:cc:subject:date:message-id:in-reply-to:references; s= default; bh=JgjaX9Dyja086eJ8g7tqToYyKfo=; b=UwAHg+MUcg4HOra5wHIJ mIAVcgxbu8Sn8i3gI64TBDRn+ygt3azND8yqsZGEqqzHQQhewvojs1GCKaptuKIS Ik0VRpkKNjJ3eT7VS98927klUQqsIJMuHzrvk6a1emzVlu3olDBW0H2WnVyAFo2e Y1l5EWW3VMY6jXK8v9nh5/4= Received: (qmail 44386 invoked by alias); 13 Jun 2018 18:58:40 -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 44183 invoked by uid 89); 13 Jun 2018 18:58:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_SOFTFAIL autolearn=ham version=3.3.2 spammy=Increase X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Jun 2018 18:58:38 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fTAyX-0006se-On for gcc-patches@gcc.gnu.org; Wed, 13 Jun 2018 14:58:36 -0400 Received: from spamexpert01-s28.outgoing.host.bg ([217.174.156.200]:37427) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fTAyX-0006VX-2W for gcc-patches@gcc.gnu.org; Wed, 13 Jun 2018 14:58:33 -0400 Received: from server28.host.bg ([193.107.36.199]) by spamexpert01.outgoing.host.bg with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fTAyN-0007RZ-99 for gcc-patches@gcc.gnu.org; Wed, 13 Jun 2018 21:58:24 +0300 Received: from [95.87.234.74] (port=54300 helo=localhost.localdomain) by server28.host.bg with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1fTAyL-002tSX-4P; Wed, 13 Jun 2018 21:58:21 +0300 From: Dimitar Dimitrov To: gcc-patches@gcc.gnu.org Cc: Dimitar Dimitrov Subject: [PATCH 11/11] Increase MAX_MAX_OPERANDS limit Date: Wed, 13 Jun 2018 21:58:05 +0300 Message-Id: <20180613185805.7833-12-dimitar@dinux.eu> In-Reply-To: <20180613185805.7833-1-dimitar@dinux.eu> References: <20180613185805.7833-1-dimitar@dinux.eu> X-AuthUser: dimitar@dinux.eu X-SpamExperts-Domain: server28.host.bg X-SpamExperts-Username: 193.107.36.199 Authentication-Results: outgoing.host.bg; auth=pass smtp.auth=193.107.36.199@server28.host.bg X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: SB/global_tokens (0.00422319475528) X-Recommended-Action: accept X-Report-Abuse-To: spam@spamexpert01.outgoing.host.bg X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 217.174.156.200 X-IsSubscribed: yes The PRU load/store instructions can access memory with byte granularity for all 30 of its 32-bit GP registers. Examples: # Load 17 bytes from address r0[0] into registers r10.b1-r14.b2 lbbo r10.b1, r0, 0, 17 # Load 100 bytes from address r28[0] into registers r0-r25 lbbo r0.b0, r28, 0, 100 The load/store multiple patterns declare all subsequent registers as distinct operands. Hence the need to increase the limit. Increase the value to just 60 in order to avoid modifying regrename.c. 2018-06-13 Dimitar Dimitrov * genoutput.c (MAX_MAX_OPERANDS): Increase to 60. Signed-off-by: Dimitar Dimitrov --- gcc/genoutput.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/genoutput.c b/gcc/genoutput.c index 06456f4400c..d2eb179e813 100644 --- a/gcc/genoutput.c +++ b/gcc/genoutput.c @@ -96,7 +96,7 @@ along with GCC; see the file COPYING3. If not see arbitrary limit, but what machine will have an instruction with this many operands? */ -#define MAX_MAX_OPERANDS 40 +#define MAX_MAX_OPERANDS 60 static char general_mem[] = { TARGET_MEM_CONSTRAINT, 0 };