From patchwork Sat Jul 23 12:40:02 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Patrick Palka X-Patchwork-Id: 651957 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3rxRwM63Kdz9t1g for ; Sat, 23 Jul 2016 22:41:37 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=kIrnInZN; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; q=dns; s=default; b=ieZqjR8JtT8/ dXxWse1A8qA5X2jxTxeSaZ2p4KdDeymKrzIO8fSvXHk8ahJFTryfNUY+poeOt2wP zl1NktEKysuCeHn2zMve+MmjVGt0duTbvr8NjspO1FcRPwxTRHCPj9TtnJWDNRne edE1kA+nASn3Q4aMWP/hRhWVCXL1Bo8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id; s=default; bh=VZWUmory1fGbycmAiB 2hs3QOOm8=; b=kIrnInZNr8lPNpHDUBZx5EK8xA6/joJs/Hev+eD+f5z4r5ZK0A pfk2QxFAmQrXekWnzDc5O6nDgxDfGXTN3Z2j/lSmdeOVZGNAO/nDlAiK49rWVDx9 a4khegWT274Aj+ep31wBRwkvfpE0xYcEpMdclqqe/qMFtObcO97PoD8Oc= Received: (qmail 114457 invoked by alias); 23 Jul 2016 12:41:28 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 114394 invoked by uid 89); 23 Jul 2016 12:41:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=invert, bare, H*Ad:D*cx X-HELO: mail-qk0-f196.google.com Received: from mail-qk0-f196.google.com (HELO mail-qk0-f196.google.com) (209.85.220.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Sat, 23 Jul 2016 12:41:16 +0000 Received: by mail-qk0-f196.google.com with SMTP id p126so10508881qke.1 for ; Sat, 23 Jul 2016 05:41:16 -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:cc:subject:date:message-id; bh=ehfmXS8GfgMSXM6OiwJn9QxYKavZLSEqRYWt3HlJh38=; b=C2a1nHl/R0h3MoHpo/MEo2/k6yK85YFfSFpG7gnpISpq2+EBWtpyPzKzT2zs+0h/XA bubjZdBfwFDvsjhOOAJRcNnr5wZpfT21veC63icWD4HxeFCO8I5UOtA78FBkZccMpm3d ZXznv+vfBnvxRGxdId2aHbklKshL6+58Guh82cAt6gP0mkidR5GFwLj9KzV1bZaWf0ra Kt+yJdkYKa/pzEb4f6pFyhZvgxCw5nkULsZ+RUs7bqrFUiTT7J5vzCL6QE4odtCVAOn9 YPKRxSs2UZKyIFxLJY2/LxYL7N+UBiH2b6ZOZt4LnHsieYsRZYnKQ4a3SeuwcAtiy7dU gj9w== X-Gm-Message-State: AEkoouukgCqtR5h/GH17UYPbAr0px74L8HlWMUes4hhSaScN2b/Lxwigu0DoKv3PnUX+Ew== X-Received: by 10.55.133.197 with SMTP id h188mr10834341qkd.165.1469277674534; Sat, 23 Jul 2016 05:41:14 -0700 (PDT) Received: from localhost.localdomain (ool-4353abbc.dyn.optonline.net. [67.83.171.188]) by smtp.gmail.com with ESMTPSA id s16sm10027017qke.14.2016.07.23.05.41.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Jul 2016 05:41:13 -0700 (PDT) From: Patrick Palka To: gcc-patches@gcc.gnu.org Cc: Patrick Palka Subject: [PATCH] Minor changes in tree-vrp.c Date: Sat, 23 Jul 2016 08:40:02 -0400 Message-Id: <20160723124002.18565-1-patrick@parcs.ath.cx> 1. When dumping assert details, print loc->expr instead of the bare SSA name. loc->expr is not always equal to the SSA name. For example we sometimes insert an ASSERT_EXPR like x_7 = ASSERT_EXPR 8>; The diff of the new dump output looks like: Assertions to be inserted for x_4(D) if (_4 <= 8) BB #3 EDGE 2->3 2 [39.0%] (FALSE_VALUE,EXECUTABLE) - PREDICATE: x_4(D) gt_expr 8 + PREDICATE: (unsigned int) x_4(D) + 4294967295 gt_expr 8 2. In extract_code_and_val_from_cond_with_ops verify that name is equal to either cond_op0 or cond_op1. If name is not equal to one of these operands then its caller register_edge_assert_for will malfunction and the wrong assertion will get inserted. Is this OK to commit after bootstrap + regtesting? gcc/ChangeLog: * tree-vrp.c (dump_asserts_for): Print loc->expr instead of name. (extract_code_and_val_from_cond_with_ops): Verify that name is either cond_op0 or cond_op1. --- gcc/tree-vrp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c index a3068ec..5072370 100644 --- a/gcc/tree-vrp.c +++ b/gcc/tree-vrp.c @@ -4827,7 +4827,7 @@ dump_asserts_for (FILE *file, tree name) dump_edge_info (file, loc->e, dump_flags, 0); } fprintf (file, "\n\tPREDICATE: "); - print_generic_expr (file, name, 0); + print_generic_expr (file, loc->expr, 0); fprintf (file, " %s ", get_tree_code_name (loc->comp_code)); print_generic_expr (file, loc->val, 0); fprintf (file, "\n\n"); @@ -5009,13 +5009,15 @@ extract_code_and_val_from_cond_with_ops (tree name, enum tree_code cond_code, comp_code = swap_tree_comparison (cond_code); val = cond_op0; } - else + else if (name == cond_op0) { /* The comparison is of the form NAME COMP VAL, so the comparison code remains unchanged. */ comp_code = cond_code; val = cond_op1; } + else + gcc_unreachable (); /* Invert the comparison code as necessary. */ if (invert)