From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11359 invoked by alias); 18 Mar 2010 21:30:17 -0000 Received: (qmail 11328 invoked by uid 22791); 18 Mar 2010 21:30:13 -0000 X-SWARE-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,BAYES_00,MEDICAL_SUBJECT,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 18 Mar 2010 21:30:04 +0000 Received: from mail.codesourcery.com ([38.113.113.100]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NsNI2-0002IV-I0 for gcc@gcc.gnu.org; Thu, 18 Mar 2010 17:30:02 -0400 Received: (qmail 20854 invoked from network); 18 Mar 2010 21:29:59 -0000 Received: from unknown (HELO ?128.107.165.182?) (wilson@127.0.0.2) by mail.codesourcery.com with ESMTPA; 18 Mar 2010 21:29:59 -0000 Subject: Re: Question on mips multiply patterns in md file From: Jim Wilson To: "Amker.Cheng" Cc: gcc@gcc.gnu.org In-Reply-To: References: <4B9E9ACF.1000707@codesourcery.com> <1268853369.2587.20.camel@localhost> Content-Type: text/plain Date: Thu, 18 Mar 2010 22:58:00 -0000 Message-Id: <1268947799.3285.12.camel@localhost> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 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: 2010-03/txt/msg00276.txt.bz2 On Thu, 2010-03-18 at 19:20 +0800, Amker.Cheng wrote: > Does it possible that the method would ever result in register > allocator failure? > In my understanding, doesn't reload pass would do whatever it can to make > all insns' constraints satisfied? In theory, there should be no failure. In practice, maybe there will be. Lots of things in gcc are more complicated than they appear to be at first, and reload is the biggest one. The question in my mind is why does the mul_acc_si pattern have two alternatives? Maybe the second alternative was added as an obscure minor optimization. Or maybe it was added to fix an obscure register allocator failure. Without more info, it is impossible to know, and thus unsafe to make assumptions about which one is true. We may be able to find which one is true by looking at gcc history though. If we can find the ChangeLog entry and/or the patch that added the second alternative, that may tell us why the second alternative is there. > By this , you mean I should go back to the define_split method if dropping > the alternative does results in bad insns generated by RA? Use the define_split method if dropping the alternative results in reload aborting, or if dropping the alternative results in code that is less efficient than the code you get with the define_split. > Another thought on this topic, Maybe I should make two copy of mul_acc_si > like you said, with one remains the constraints, the other drop the "*?*?". > Does this is the same as your method suggested? Yes, that is another possibility. This makes the first alternative more desirable, and thus reduces the number of times the second alternative is chosen, but still allows the second one to be chosen in some cases when it might be better. This might even be a better solution than the first two we had. The only way to know is to do some experimenting, looking at assembly code to see what happens with the different choices. Jim