From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11548 invoked by alias); 11 Oct 2011 02:58:15 -0000 Received: (qmail 11533 invoked by uid 22791); 11 Oct 2011 02:58:14 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mailout03.t-online.de (HELO mailout03.t-online.de) (194.25.134.81) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Oct 2011 02:57:58 +0000 Received: from fwd10.aul.t-online.de (fwd10.aul.t-online.de ) by mailout03.t-online.de with smtp id 1RDSXU-0007Cl-GJ; Tue, 11 Oct 2011 04:57:56 +0200 Received: from [192.168.0.104] (EY2fE-Zp8h9H3L6pHeRLQIHmL3rJkugdHd0VU36TxDvYgCNyPl1JuTiXbILpcovQEG@[93.218.186.15]) by fwd10.t-online.de with esmtp id 1RDSXJ-1kLXl20; Tue, 11 Oct 2011 04:57:45 +0200 Subject: Combine Pass Behavior From: Oleg Endo To: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 Oct 2011 12:21:00 -0000 Message-ID: <1318301863.19997.311.camel@yam-132-YW-E178-FTW> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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/msg00171.txt.bz2 Hi all, I'm currently trying to find the best way to solve PR 49263 and I've ran into some questions regarding the combine pass. Summary of the story: The SH machine description has a pattern that is supposed to generate the "tst #imm, r0" instruction as a combination of an and and a comparison, where #imm is an unsigned byte (0...255): (define_insn "" [(set (reg:SI T_REG) (eq:SI (and:SI (match_operand:SI 0 "arith_reg_operand" "z,r") (match_operand:SI 1 "logical_operand" "K08,r")) (const_int 0)))] "TARGET_SH1" "tst %1,%0" [(set_attr "type" "mt_group")]) However, the combine pass does not find this pattern for certain bit patterns, because it tries to combine the two insns.. (insn 10 7 11 2 (set (reg:SI 170) (and:SI (reg/v:SI 164 [ x ]) (const_int 4 [0x4]))) {*andsi3_compact} (expr_list:REG_DEAD (reg/v:SI 164 [ x ]) (nil))) (insn 11 10 17 2 (set (reg:SI 147 t) (eq:SI (reg:SI 170) (const_int 0 [0]))) {cmpeqsi_t} (expr_list:REG_DEAD (reg:SI 170) (nil))) into something like this.... (set (reg:SI 147 t) (eq:SI (zero_extract:SI (reg:SI 4 r4 [ x ]) (const_int 2 [0x2]) (const_int 0 [0])) (const_int 0 [0]))) or .. (set (reg:SI 147 t) (zero_extract:SI (xor:SI (reg:SI 4 r4 [ x ]) (const_int 4 [0x4])) (const_int 1 [0x1]) (const_int 2 [0x2]))) or .. (set (reg:SI 168) (and:SI (not:SI (reg:SI 4 r4 [ x ])) (const_int 1 [0x1]))) .. and a couple of other variants. The actual problem (or maybe my misunderstanding) is that it combines the two original insns, then does some substitutions and tries to match the combined and transformed insn against those defined in the machine description. If it can't find anything there it reverts everything and proceeds with the next insn pair. It never tries out the straight forward option in the first place (which is not to transform the combination). As a quick hack for myself I've added a second combine pass (ran after the original combine pass) where the function make_compound_operation (rtx x, enum rtx_code in_code) simply returns x instead of expanding it into a zero_extract. This fixed most of the issues at hand, but doesn't sound quite right. Is the scenario above intended behavior of the combine pass or an accident? Or maybe even something else wrong in the machine description that makes it behave like that? At least it sounds very related to PR 30829. Thanks, Oleg