From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13451 invoked by alias); 5 Dec 2001 17:52:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13409 invoked from network); 5 Dec 2001 17:52:23 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 5 Dec 2001 17:52:23 -0000 Received: (from hubicka@localhost) by atrey.karlin.mff.cuni.cz (8.9.3/8.9.3/Debian 8.9.3-21) id SAA09831; Wed, 5 Dec 2001 18:52:23 +0100 Date: Wed, 05 Dec 2001 09:52:00 -0000 From: Jan Hubicka To: dimmy Cc: Jan Hubicka , gcc@gcc.gnu.org Subject: Re: Legitimize address, Please HELP! Message-ID: <20011205185223.D1986@atrey.karlin.mff.cuni.cz> References: <3C0E1421.1080906@mail.ru> <20011205163059.M30680@atrey.karlin.mff.cuni.cz> <3C0E5775.1040904@mail.ru> <20011205181637.N12305@atrey.karlin.mff.cuni.cz> <3C0E6806.3060706@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C0E6806.3060706@mail.ru> User-Agent: Mutt/1.3.20i X-SW-Source: 2001-12/txt/msg00221.txt.bz2 > Jan, thanks for reply. > I really do not know much about the process of the creation of > instructions - only that written in gcc info. > > I will appreciate if you can tell me what's wrong with the expander like: I don't see the bug directly in expanders you quoted, but few problems: 1) match_operand calls the predicate, so memory_operand call in movhi1 condition is redundant. Similary in movhi2, where you call nonimmediate_operand that is supperset of register_operand already tested. 2) the zero_shifted/indexed_location test probably should be hid in new operand writen in your md file used in patterns instead of general_operand to make thinks cleaner. Basically the condition should mention only tests that depdends on multiple 3) "m" is wrong constraint for general_operand. Eighter you need to use memory_operand, or allow some registers and constants in the constraint. The constraints and predicates should be in "harmony" one should not be considerably stronger/weaker than the other otherwise you are asking for problems in reload pass. In case the second pattern is expected to load address as integer value (i386 lea equivalent), it should use (match_operand "address_operand" "a"), not memory and should come last to avoid matches in dumb cases. 4) For speed you should probably move more probable movhi3 first. 5) All three patterns can be single pattern with multiple alternative output template. This will result in faster compiler and better produced code if you do so. Some late passes, as reload, do not take a look if different pattern match, only test if given pattern and usually also alternative, allow the suggested optimization. 6) Similary you can collapse multiple alternatives to single: "=m,r,r,m,r,m,m,r m,r,P,P,m,r,i,i" can be: "=m ,r" mrPi,mrPi" Also it is good to prohibit mem->mem move in the conditional + add expander to split it into two instructions early like i386.md does. Otherwise the need for register in this case is discovered late in the register allocation progress often resulting in dumb spill. In case you do have flags register (as cc attribute suggest), please consider not using cc0, as it looks you do use. We are tying to zap that. Look at i386.md/sparc.md about how new backends are usually done. Concerning your problem. The problematic piece of code is not contained in the mov expander, instead it is, most probably, some other code generating the add/mov directly and getting thinks wrong. one of ways to get it is to add test for current_insn_uid in emit-rtl.c and break program in debugger when offending instruction is emit. Then you will be probably able to figure out where it incarned. See the gcc readings page. I believe there are some links to other porting docs, than the gcc manual itself. it is good idea to read them (even when I never did :), because it can save you some headaches later. Hope this helps, Honza > > ======================== > (define_expand "movhi" > [(set (match_operand:HI 0 "nonimmediate_operand" "") > (match_operand:HI 1 "general_operand" ""))] > "" > "") > > > (define_insn "*movhi1" > [(set (match_operand:HI 0 "memory_operand" "=m") > (match_operand:HI 1 "general_operand" "m"))] > "( memory_operand(operands[0], VOIDmode) > && !register_operand(operands[0], VOIDmode) > && zero_shifted(operands[1]) > && indexed_location(operands[1]))" > "mov\\t@%E1, %0" > [(set_attr "length" "3") > (set_attr "cc" "none")]) > > > (define_insn "*movhi2" > [(set (match_operand:HI 0 "register_operand" "=r") > (match_operand:HI 1 "general_operand" "m"))] > "(nonimmediate_operand(operands[0], VOIDmode) > && zero_shifted(operands[1]) > && indexed_location(operands[1]) )" > "mov\\t@%E1, %A0" > [(set_attr "length" "2") > (set_attr "cc" "none")]) > > (define_insn "*movhi3" > [(set (match_operand:HI 0 "nonimmediate_operand" "=m,r,r,m,r,m,m,r") > (match_operand:HI 1 "general_operand" " > m,r,P,P,m,r,i,i"))] > "(nonimmediate_operand(operands[0], HImode) > && !zero_shifted(operands[1]) > && !indexed_location(operands[1]) )" > "mov\\t%1, %0 " > [(set_attr "length" "1,3,1,2,2,2,3,2") > (set_attr "cc" "none")]) > ==============================