From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28771 invoked by alias); 22 Aug 2004 23:59:25 -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 28760 invoked from network); 22 Aug 2004 23:59:24 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 22 Aug 2004 23:59:24 -0000 Received: (qmail 10523 invoked from network); 22 Aug 2004 23:59:21 -0000 Received: from taltos.codesourcery.com (zack@66.92.218.83) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 22 Aug 2004 23:59:21 -0000 Received: by taltos.codesourcery.com (sSMTP sendmail emulation); Sun, 22 Aug 2004 16:59:22 -0700 To: Richard Sandiford Cc: gcc@gcc.gnu.org Subject: Re: RFC: Using mode and code macros in *.md files References: <87vffux323.fsf@redhat.com> From: Zack Weinberg Date: Mon, 23 Aug 2004 10:32:00 -0000 In-Reply-To: <87vffux323.fsf@redhat.com> (Richard Sandiford's message of "Sat, 07 Aug 2004 18:37:08 +0100") Message-ID: <87wtzq4td1.fsf@codesourcery.com> User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-08/txt/msg01064.txt.bz2 Richard Sandiford writes: > This is an RFC about using mode and code macros in *.md files. > I've attached a patch that implements the suggested constructs > and an example of how they might be used in mips.md. This is rather belated, but I'd like to throw in a few comments. In general I really like this, it looks like it's got potential to make it much easier to write machine descriptions. I've got some suggestions, though, which which I think can be implemented as incremental improvements to the patch you've already got. 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. 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. 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. zw