From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101454 invoked by alias); 15 Jun 2016 18:08:13 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 101046 invoked by uid 89); 15 Jun 2016 18:08:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*MI:googlemail, H*M:googlemail, Hx-languages-length:2776 X-HELO: mail-lb0-f193.google.com Received: from mail-lb0-f193.google.com (HELO mail-lb0-f193.google.com) (209.85.217.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 15 Jun 2016 18:08:01 +0000 Received: by mail-lb0-f193.google.com with SMTP id t6so944236lbv.1 for ; Wed, 15 Jun 2016 11:08:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:mail-followup-to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version; bh=0V+fG5sGvCclGsLydoo862suhDMsjYq4nLqn8g+Yp5M=; b=GZZ3j1kTa0E852k6JjUxtttokbZhvviz7wq3nHnVel0SJSMzrZK1ghO6p9vWgx1ekE Xk7Kc8luLkeDVaAb/tJ0hdOYzdCVY4HYc0R5aQjT7dbBKjFrHl8N6iJqyVajQuAZd7pD zgGHqi5FM6qmv8rx7POtFy5uGsm2wI0jDd6y/O3NeFOIaqceYClzdChM+/O+YFdot3rb NWkt4vA98U4Jb2gRCEYP/kAcZCg2erGhLCNffc6Xf447DWH6Lo6YFE7YfueZLd3/EWwU QOucGa5YnIOjxrs6JW5VnF7sdszAITQvsabIPAao+FLQp8sN8pkbMmnfvbeQjSUCDU21 kGqg== X-Gm-Message-State: ALyK8tIhBI3vKCEdgri6UP/Xq2h9liAu3n7ryKBsVQWAharmnMdfzqS01TTFDRdGl663Gw== X-Received: by 10.28.167.69 with SMTP id q66mr600963wme.100.1466014078235; Wed, 15 Jun 2016 11:07:58 -0700 (PDT) Received: from localhost ([2.26.27.170]) by smtp.googlemail.com with ESMTPSA id o203sm5376411wmg.22.2016.06.15.11.07.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Jun 2016 11:07:57 -0700 (PDT) From: Richard Sandiford To: Andrew Burgess Mail-Followup-To: Andrew Burgess ,gcc-patches@gcc.gnu.org, Joern Wolfgang Rennecke , rdsandiford@googlemail.com Cc: gcc-patches@gcc.gnu.org, Joern Wolfgang Rennecke Subject: Re: [PATCH 2/2] gcc/genrecog: Don't warn for missing mode on special predicates References: <65124582452f1e6ba9f95992684363b0ae5ef0be.1465946922.git.andrew.burgess@embecosm.com> Date: Wed, 15 Jun 2016 18:08:00 -0000 In-Reply-To: <65124582452f1e6ba9f95992684363b0ae5ef0be.1465946922.git.andrew.burgess@embecosm.com> (Andrew Burgess's message of "Wed, 15 Jun 2016 00:38:10 +0100") Message-ID: <87bn32tjer.fsf@googlemail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-06/txt/msg01173.txt.bz2 Andrew Burgess writes: > In md.texi it says: > > Predicates written with @code{define_special_predicate} do not get any > automatic mode checks, and are treated as having special mode handling > by @command{genrecog}. > > However, in genrecog, when validating a SET pattern, if either the > source or destination is missing a mode then a warning is given, even if > there's a predicate defined with define_special_predicate. > > This commit silences the warning for special predicates. > > gcc/ChangeLog: > > * genrecog.c (validate_pattern): Don't warn about missing mode for > define_special_predicate predicates. > Acked-by: Andrew Burgess > --- > gcc/ChangeLog | 5 +++++ > gcc/genrecog.c | 22 +++++++++++++++++++--- > 2 files changed, 24 insertions(+), 3 deletions(-) > > diff --git a/gcc/genrecog.c b/gcc/genrecog.c > index a9f5a4a..7596552 100644 > --- a/gcc/genrecog.c > +++ b/gcc/genrecog.c > @@ -674,9 +674,25 @@ validate_pattern (rtx pattern, md_rtx_info *info, rtx set, int set_code) > && !CONST_WIDE_INT_P (src) > && GET_CODE (src) != CALL) > { > - const char *which; > - which = (dmode == VOIDmode ? "destination" : "source"); > - message_at (info->loc, "warning: %s missing a mode?", which); > + const char *which_msg; > + rtx which; > + const char *pred_name; > + const struct pred_data *pred; > + > + which_msg = (dmode == VOIDmode ? "destination" : "source"); > + which = (dmode == VOIDmode ? dest : src); > + pred_name = XSTR (which, 1); > + if (pred_name[0] != 0) > + { > + pred = lookup_predicate (pred_name); > + if (!pred) > + error_at (info->loc, "unknown predicate '%s'", pred_name); > + } > + else > + pred = 0; > + if (!pred || !pred->special) > + message_at (info->loc, "warning: %s missing a mode?", > + which_msg); There's no guarantee at this point that "which" is a match_operand. Also, I think the earlier: /* The operands of a SET must have the same mode unless one is VOIDmode. */ else if (dmode != VOIDmode && smode != VOIDmode && dmode != smode) error_at (info->loc, "mode mismatch in set: %smode vs %smode", GET_MODE_NAME (dmode), GET_MODE_NAME (smode)); should be skipped for special predicates too. How about generalising: /* The mode of an ADDRESS_OPERAND is the mode of the memory reference, not the mode of the address. */ if (GET_CODE (src) == MATCH_OPERAND && ! strcmp (XSTR (src, 1), "address_operand")) ; to: if (special_predicate_operand_p (src) || special_predicate_operand_p (dest)) ; with a new special_predicate_operand_p helper? I don't think we should duplicate the "unknown predicate" error here; the helper can just return false for unknown predicates. Thanks, Richard