From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27331 invoked by alias); 26 Oct 2011 03:53:25 -0000 Received: (qmail 27320 invoked by uid 22791); 26 Oct 2011 03:53:24 -0000 X-SWARE-Spam-Status: No, hits=-1.4 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 03:53:10 +0000 Received: from unknown (HELO webmail2) ([192.168.1.183]) by c60.cesmail.net with ESMTP; 25 Oct 2011 23:53:09 -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 23:54:18 -0400 Message-ID: <20111025235418.zpx3lbg5esw0ww8s-nzlynne@webmail.spamcop.net> Date: Wed, 26 Oct 2011 15:38:00 -0000 From: Joern Rennecke To: DJ Delorie Cc: gcc@gcc.gnu.org Subject: Re: 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> <20111025202444.4fr6ofn1kogkc0co-nzlynne@webmail.spamcop.net> <201110260155.p9Q1tJ0l015827@greed.delorie.com> <20111025225812.6t04cg8mecckocoo-nzlynne@webmail.spamcop.net> <201110260304.p9Q34Twx017783@greed.delorie.com> In-Reply-To: <201110260304.p9Q34Twx017783@greed.delorie.com> 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/msg00466.txt.bz2 Quoting DJ Delorie : > >> I was talking about what addresses are allowed by the >> TARGET_LEGITIMATE_ADDRESS_P, not what the hardware implements or >> what the register allocator is guided to produce; some optimizers >> can get quite 'creative' in mashing rtl together. > > I've never seen it actually do that and get it past the backend, but > if they're doing it now, I suppose that logic is no longer sufficient. Well, this pattern was freely invented, but I've seen the combiner folding arithmetic and other memory references in place of a register inside a memory address when you give it the opportunity (for a different port). Operand predicates matter, and what memory_operand / address_operand accept is largely determined by TARGET_LEGITIMATE_ADDRESS_P. But my original point wasn't so much about this potential/latent problem in the m32c port as such, as that this is a pathway by which=20=20 dse.c:emit_inc_dec_insn_before could find itself with some mighty=20=20 strange autoincrement addresses which it would attempt to convert to additions. These would generally not be recognized by the addition - or any other existing - patterns. However, if we discount these weird patterns - be that because 'that never happens' or because they are blocked by a few more checks in the target hook, so that the offset in a recognized PRE_MODI= FY is always a valid operand, the m32c addhi3 insn pattern will work, no matter if you go the optabs route, or use the current raw rtl generation in dse.c:emit_inc_dec_insn_before . OTOH, if the PRE_MODIFY is malformed, you are likely to end up with an ICE, no matter which way you try to make it into an add, and even if you leave it alone, it is not likely to end in the successful generation of a working program. So, although the analysis shows the m32c is not entirely in the clear with regards to the dead store with auto-increment -> add=20=20 transformation, and problem there is not really a dse problem. mn10300, rx and stormy16 show a problem with a flags register clobber. If the avr wanted to sched cc0, it would join these ranks. The Epiphany has the further interesting aspect that some additions that can be done with a post_modify have a wider offset range than an add.