From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18384 invoked by alias); 26 Oct 2011 00:25:01 -0000 Received: (qmail 18369 invoked by uid 22791); 26 Oct 2011 00:25:00 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MIME_QP_LONG_LINE X-Spam-Check-By: sourceware.org Received: from c60.cesmail.net (HELO c60.cesmail.net) (216.154.195.49) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 26 Oct 2011 00:24:45 +0000 Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c60.cesmail.net with ESMTP; 25 Oct 2011 20:24:44 -0400 Received: from host-92-29-214-155.as13285.net (host-92-29-214-155.as13285.net [92.29.214.155]) by webmail.spamcop.net (Horde MIME library) with HTTP; Tue, 25 Oct 2011 20:24:44 -0400 Message-ID: <20111025202444.4fr6ofn1kogkc0co-nzlynne@webmail.spamcop.net> Date: Wed, 26 Oct 2011 02:58:00 -0000 From: Joern Rennecke To: gcc@gcc.gnu.org Cc: law@redhat.com, aoliva@redhat.com, nickc@redhat.com Subject: Impact assessment of dse.c:emit_inc_dec_insn_before (Was: Re: Use of FLAGS_REGNUM clashes with generates insn) References: <20110923032116.4fzwmhwd44ckgwwk-nzlynne@webmail.spamcop.net> <20111018062749.ff87vnia88g0kkc8-nzlynne@webmail.spamcop.net> In-Reply-To: <20111018062749.ff87vnia88g0kkc8-nzlynne@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) 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 X-SW-Source: 2011-10/txt/msg00460.txt.bz2 Quoting amylaar@spamcop.net: > The issue with this patch is that we'll have to check if gen_add3_insn mi= ght > fail on any target, and also we have to identify on which targets it will > create an insn that clobbers potentially live hard registers > (like a flags register), and make the substitution fail in this case. > I.e. if in doubt, keep the dead store with the auto-increment. > But not fail for a target that knows what it clobbers in a > reload_in_progress / reload_completed add. I've gone through the machine description that define one of the HAVE_P\(RE\|OST\)_.* macros, and checked if the auto-increment addresses they accept can be replaced with an add, both when using gen_add3_insn, which goes via optabs and named patterns, and by recognizing the rtl that dse.c:emit_inc_dec_insn_before generates without any proper checks. I've added the maintainers of ports that appear to get auto-increments turned into flag-clobbering adds (excluding cc0) to the Cc: list. Note that the auto-increment offset range in this summary only states what the GCC machine description says; for various reasons, the actual hardware capabilities might be more or less. "insn pattern" means that the add pattern for Pmode (one of addhi3 / addsi3= / adddi3 / addpsi3) is a named instruction patterns and is thus used both when expanding using gen_add3_insn, and to recognize the add. I have looked at the offset range for any auto-increment use, even though at times only a smaller range is available for stores; it turned out that the addition range is not actually a problem for the existing targets. architecture Pmode offset addP3 src,src,srcoff with PRE/POST INC/DEC/MODIFY arm SImode -255..255 expand, recog OK. arm SImode (-255..255)*4 expand, recog OK. avr HImode -4..4 expand, recog OK (costly & need cc0) bfin SImode -8..8 insn pattern, breaks on IREGS, PDImo= de. c6x SImode -8..8 insn pattern, breaks on REG_ILC cris SImode 1..8 expand, recog OK. frv SImode reg only insn pattern, OK. h8300 HImode/SImode -4..+4 expand, recog OK. ia64 DImode -256..255 insn pattern, OK. m32c HImode/PSImode -8..8/NaN insn pattern, OK if offset is operan= d. m32r SImode -4/4 insn pattern, OK. m68k SImode -8..8 expand, recog OK. mn10300 SImode any integer insn pattern, has CC_REG clobber. recog of naked (set ...=20=20 (plus)) will fail pa SImode -8..8 insn pattern, OK. pa DImode -8..8 expand, recog OK. pdp11 HImode -8..8 insn pattern, OK. rs6000 SImode/DImode -0x8000..0x7fff expand, recog OK. rx SImode -4..4 expand, recog with CC_REG clobber. recog of naked (set ...=20=20 (plus)) will fail score SImode -4..4 expand, recog OK. sh SImode -8..8 expand, recog OK. sh64 DImode N/A stormy16 HImode any integer insn pattern, has CARRY_REG clobber. ALL REGISTERS ARE ALLOWED AS ADDRESS REGISTERS, BUT ONLY TWO CAN BE USED IN AN ADD INSN. Calling gen_addh= i3 with a non-general register operand after reload will gene= rate an insn that fails to match its constraints. vax SImode -8..8 insn pattern, OK. m32c.c:m32c_legitimate_address_p allows any rubbish inside a PRE_MODIFY, as long as the address register is the stack pointer. OTOH, it does not define any HAVE_*_MODIFY_* macro. score defines HAVE_PRE_MODIFY_DISP and HAVE_POST_MODIFY_DISP, but rejects PRE_MODIFY / POST_MODIFY in TARGET_LEGITIMATE_ADDRESS_P . It appears the dse problem can currently cause ICE-on-valid for=20=20 mn10300 and rx, which could be changed by my original patch into sporadic wrong-code generation, when CC_REG happens to be live. OTOH when CC_REG is free, we get working code instead of the ICE. The situation is similar for stormy16 unless a register is used as an address register that is not suitable for an add - which would continue to get ICEs.