From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11257 invoked by alias); 26 Aug 2004 19:01:15 -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 11229 invoked from network); 26 Aug 2004 19:01:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 26 Aug 2004 19:01:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i7QJ17S0009185; Thu, 26 Aug 2004 15:01:07 -0400 Received: from localhost (mail@vpnuser9.surrey.redhat.com [172.16.9.9]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i7QJ16308463; Thu, 26 Aug 2004 15:01:06 -0400 Received: from rsandifo by localhost with local (Exim 3.35 #1) id 1C0PUf-00067y-00; Thu, 26 Aug 2004 20:01:05 +0100 To: Zack Weinberg Cc: gcc@gcc.gnu.org Subject: Re: RFC: Using mode and code macros in *.md files References: <87vffux323.fsf@redhat.com> <87wtzq4td1.fsf@codesourcery.com> From: Richard Sandiford Date: Thu, 26 Aug 2004 21:08:00 -0000 In-Reply-To: <87wtzq4td1.fsf@codesourcery.com> (Zack Weinberg's message of "Sun, 22 Aug 2004 16:59:22 -0700") Message-ID: <87u0upd8r2.fsf@redhat.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01335.txt.bz2 Zack Weinberg writes: > First thing is, Pmode is a bit of a special case. For one thing, > we've got a "pmode_register_operand" predicate which does exactly what > you want for *this* use of Pmode. You could write > > (define_insn "indirect_jump_internal" > [(set (pc) (match_operand 0 "pmode_register_operand" "d"))] > "" > "%*j\t%0%/" > [(set_attr "type" "jump") > (set_attr "mode" "none")]) > > However, this doesn't help with any other place where one would like > to use a :P mode suffix. And I agree that :P should work. > > The other way Pmode is special is that it's already defined by every > target, and it would be nice if every target didn't have to re-specify > it with a mode macro in order to get it to work in the machine > description. When Pmode is a compile-time constant, in fact, you > ought to get the same code out of gen* that you would if you > search-and-replaced every :P in the machine description with the > underlying mode. With the current implementation, it would be fairly easy to define Pmode (and ptr_mode and word_mode?) in the *.md file and get the gen* programs to generate the #define automatically. There would just need to be new constructs specifically for "one of" (as opposed to "any of") macros. However... > When it's not a compile-time constant the question becomes more > difficult, but I think it's still doable; one has to think carefully > about the code that genrecog would have to emit, but the rest of the > generated code doesn't change much. ...it sounds like you're thinking about _generating_ single Pmode patterns, even when the target has more than one pointer mode. Is that right? I did wonder about that, but it decided it would be a lot of work. It would mean auditing all uses of insn_data[] (including reload, yikes!) so that operand[].modes of Pmode are converted to the appropriate "real" mode in time. I guess one way would be to define new accessor functions for insn_data[] and make the mode accessor do the conversion. It would also mean auditing most uses of modes in the gen* programs. As you say, things like genrecog would have to be changed so that the optimiser no longer says "is this the same mode as that?" but rather "do these two modes overlap?". I still agree this is a good idea though. > The other thing I wonder about is extension to places where the > pattern varies, not just the strings. For instance, consider the > floating point patterns in ia64.md. Notionally, every DFmode pattern > is multiplied fourfold, like so: > > (define_insn "adddf3" > [(set (match_operand:DF 0 "fr_register_operand" "=f") > (plus:DF (match_operand:DF 1 "fr_register_operand" "%f") > (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))] > "" > "fadd.d %0 = %1, %F2" > [(set_attr "itanium_class" "fmac")]) > > (define_insn "*adddf3_alts" > [(set (match_operand:DF 0 "fr_register_operand" "=f") > (plus:DF (match_operand:DF 1 "fr_register_operand" "%f") > (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))) > (use (match_operand:SI 3 "const_int_operand" ""))] > "" > "fadd.d.s%4 %0 = %1, %F2" > [(set_attr "itanium_class" "fmac")]) > > (define_insn "*adddf3_trunc" > [(set (match_operand:SF 0 "fr_register_operand" "=f") > (float_truncate:SF > (plus:DF (match_operand:DF 1 "fr_register_operand" "%f") > (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))))] > "" > "fadd.s %0 = %1, %F2" > [(set_attr "itanium_class" "fmac")]) > > (define_insn "*adddf3_trunc_alts" > [(set (match_operand:SF 0 "fr_register_operand" "=f") > (float_truncate:SF > (plus:DF (match_operand:DF 1 "fr_register_operand" "%f") > (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG")))) > (use (match_operand:SI 3 "const_int_operand" ""))] > "" > "fadd.s.s%4 %0 = %1, %F2" > [(set_attr "itanium_class" "fmac")]) > > You won't actually find these "_alts" patterns in ia64.md, because > they haven't been added consistently, but you will find the "_trunc" > variant. Now, this was definitely out of scope of your original > patch, and (since the extra patterns are for matching only) it might > be feasible to use match_operator for them. In fact, that's on my > list of things to try in the near future. But if I do do it with > match_operator, the result may not be all that readable, and the code > one has to write for a nontrivial match_operator predicate isn't > exactly nice, either. So I'm curious if you have any ideas for how to > handle this sort of thing. Couldn't you use code macros to cover all the binary operations in one go? I.e. have one pattern that implements all the binary *_alts, one that implements all the binary *_truncs, etc. Something like: (define_code_macro float_operator [plus ...]) (define_code_attr insn [(plus "fadd") ...]) (define_code_attr class [(plus "fmac") ...]) ... (define_insn "*df3_alts" [(set (match_operand:DF 0 "fr_register_operand" "=f") (float_operator:DF (match_operand:DF 1 "fr_register_operand" "%f") (match_operand:DF 2 "fr_reg_or_fp01_operand" "fG"))) (use (match_operand:SI 3 "const_int_operand" ""))] "" ".d.s%4 %0 = %1, %F2" [(set_attr "itanium_class" "")]) ... Or are the instructions not regular enough for that? [ Although, even if they are, code like the above probably isn't going to be to everyone's taste. I have started using it in the MIPS port though. ;) See yesterday's shift macroisation patch for a more concrete example. ] BTW, as a general comment, not really in reply to the above: I'm not very good at coming up with new syntax. The macro stuff was very much a case of "I want to specify these patterns from the same template" rather than "I want to write the template with this syntax". If anyone has any ideas for making templates like the above more readable, please shout ;) Richard