From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119515 invoked by alias); 16 Aug 2019 11:24:03 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 119500 invoked by uid 89); 16 Aug 2019 11:24:02 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: jocasta.intra Received: from de.cellform.com (HELO jocasta.intra) (88.217.224.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Aug 2019 11:24:00 +0000 Received: from jocasta.intra (localhost [127.0.0.1]) by jocasta.intra (8.15.2/8.15.2/Debian-8) with ESMTPS id x7GBNwjY011041 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 13:23:58 +0200 Received: (from john@localhost) by jocasta.intra (8.15.2/8.15.2/Submit) id x7GBNv4P011040; Fri, 16 Aug 2019 13:23:57 +0200 Date: Fri, 16 Aug 2019 11:24:00 -0000 From: John Darrington To: Vladimir Makarov Cc: gcc@gcc.gnu.org Subject: Special Memory Constraint [was Re: Indirect memory addresses vs. lra] Message-ID: <20190816112357.ep7fns6skm5emoey@jocasta.intra> References: <20190808172102.GH31406@gate.crashing.org> <2EEBCFAE-FF25-4664-AA5F-B3299CEA3CB1@comcast.net> <20190808191914.GK31406@gate.crashing.org> <20190809081439.baoyu3ii5i2qfbzt@jocasta.intra> <70b9bcc9-e12a-78b4-b8cc-a67b7ca3d38d@redhat.com> <20190810060553.m6e42sovw7s4xqoa@jocasta.intra> <20190815173559.kbp3uja7jklx74iy@jocasta.intra> <3c6c87ce-a38f-728d-e083-aa066d531790@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3c6c87ce-a38f-728d-e083-aa066d531790@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) X-IsSubscribed: yes X-SW-Source: 2019-08/txt/msg00121.txt.bz2 On Thu, Aug 15, 2019 at 02:23:45PM -0400, Vladimir Makarov wrote: > I tried this solution earlier. But unfortunately it makes things worse. What happens is it libgcc cannot > even be built -- ICEs occur on a memory from address reg insn such as: > (insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309) > (const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8]) > (reg:PSI 1310)) "/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi} > I see.?? Then for the insn, you could try to create a pattern "memory,special memory constraint".?? The special memory constraint should satisfy only spilled pseudo (pseudo with reg_renumber == -1).?? I believe lra-constraints.c can spill the pseudo and the end you will have mem[disp1 + r8|r9|sp] = mem[disp1+sp]. You mean something like this: (define_special_memory_constraint "a" "My special memory constraint" (match_operand 0 "my_special_predicate") ) (define_predicate "my_special_predicate" (match_operand 0 "memory_operand") { debug_rtx (op); if (MEM_P (op)) { op = XEXP (op, 0); if (GET_CODE (op) == PLUS) { op = XEXP (op, 0); if (REG_P (op)) { fprintf (stderr, "Reg number is %d\n", REGNO (op)); if (REGNO (op) >= 0) return false; } } } return true; }) When I use this I get lots of the following ICEs "internal compiler error: maximum number of generated reload insns per insn achieved (90)" It seems logical to me that this would happen since the constraint is not going to match any operand with resolved registers. Thus it will continually reload. ... which makes me think I've probably misunderstood what you are saying. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.