From patchwork Sat Aug 12 12:55:25 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luc Van Oostenryck X-Patchwork-Id: 9897101 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EE2F660236 for ; Sat, 12 Aug 2017 12:55:37 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D8284289CE for ; Sat, 12 Aug 2017 12:55:37 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id CC62E28A9C; Sat, 12 Aug 2017 12:55:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 6A159289CE for ; Sat, 12 Aug 2017 12:55:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750968AbdHLMzg (ORCPT ); Sat, 12 Aug 2017 08:55:36 -0400 Received: from mail-wm0-f67.google.com ([74.125.82.67]:34074 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750896AbdHLMzg (ORCPT ); Sat, 12 Aug 2017 08:55:36 -0400 Received: by mail-wm0-f67.google.com with SMTP id x64so9304784wmg.1 for ; Sat, 12 Aug 2017 05:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=vnvQEzD2UOe/hagzqoasZXXbQXhjLQ5sdV1b2AitJoU=; b=LdisFvZZUzRE3HECsVPSp153ogZxAaWrs/liUXKDzDwCIajBQHGzQugz4S0bc4m9l4 Lfy5zLpgYf35bN0okwrQayjn/O7qvobbwT6aPtduBvmwiAoXElqUkMsxl5pqLziZQ2dB vIIfQLlPWi+h9msaaV9aJ9636S9O3jniIkP3Ue0IoF+/3MmWHp6tB6l/f7/Y50PK4EIn T2UOf9/S2EuA1WI5d8bZDvNOxRkYWzO24VWDTGUNb3sPLIPSsqxr3UZdc0CaygKyuQFt yhWRubH56icVf9qYFdABnEnpIQIaKAq4BQ3lhVQRqw/voiIb1fjHwuOzRc9yq/Q6skbP 9+qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=vnvQEzD2UOe/hagzqoasZXXbQXhjLQ5sdV1b2AitJoU=; b=JJvRN13CQNFGnnDfjI7cUbqs2Qhk1NZPcCiYSKUiERCcl00ZLDS3L3OqC4w9oi0DJj wnAEqNbmi7tqOQkpS80Swk5cBzVRc3RQTUFCS8aZoLAQ8l1s1W/u1WYgE0xzUNGntcn0 KB4p4Kf2+329cH5q3QiMUrKK74W6WzfCwxCVh3nPMTm3SY6UE/eRpu+WG5A0kCU3rqLa lkGb3AWWImbv6RxqNIdNGcGEx0oooxHoyQ6jaoBK/+JQLCDX4M/K83cCawXLmrrzTk19 Hltq3G0tLnrmQxR+l4WlJ1EABrEHKc8QtQpVUmflnmoc30iBeil3xd1Ht3jBn7LZbUUl xZLw== X-Gm-Message-State: AHYfb5iFLwdi4m3YoEyM4XgElutYLG9ENM7DZXPt2AU7JrbELine+FRI j6kqMPFq3PFT3LfQJG4= X-Received: by 10.80.180.144 with SMTP id w16mr18648844edd.42.1502542534822; Sat, 12 Aug 2017 05:55:34 -0700 (PDT) Received: from localhost.localdomain ([2a02:a03f:4076:600:846d:f409:d179:ca81]) by smtp.gmail.com with ESMTPSA id b35sm1980293ede.2.2017.08.12.05.55.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 05:55:33 -0700 (PDT) From: Luc Van Oostenryck To: linux-sparse@vger.kernel.org Cc: Christopher Li , Luc Van Oostenryck Subject: [PATCH] avoid infinite loop during simplification Date: Sat, 12 Aug 2017 14:55:25 +0200 Message-Id: <20170812125525.34044-1-luc.vanoostenryck@gmail.com> X-Mailer: git-send-email 2.14.0 Sender: linux-sparse-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sparse@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Currently, sparse can enter in infinite loops. The effect can be seen is the normal simplification/CSE loops but the origin of the problem is not there (it's some interaction between simplify_loads() and unreachable code, at least for a good part of them). On the other hand, on normal code, the number of simplification/CSE cycle is fairly small: even in big, complex functions, in 80% of cases only 1 or 2 cycles are needed. The most extreme I found was 12 cycles and that's an unique case (on a total of 172000+). So, avoid to let sparse in infinite loop by stopping the loop if the number of cycles becomes too high: 16. Note: this solves all the 77 cases of inifinite loop I found. Note: of course, this patch doesn't change the fact that the generated IR is broken and that the root cause(s) must be addressed. Signed-off-by: Luc Van Oostenryck --- The patch is also available in the git repository at: git://github.com/lucvoo/sparse.git avoid-infinite-loop--max-cse cse.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/cse.c b/cse.c index 17b3da01a..fa136c370 100644 --- a/cse.c +++ b/cse.c @@ -356,13 +356,17 @@ static struct instruction * try_to_cse(struct entrypoint *ep, struct instruction return i1; } +#define MAX_CSE_CYCLES 16 void cleanup_and_cse(struct entrypoint *ep) { + int max = MAX_CSE_CYCLES; int i; simplify_memops(ep); repeat: repeat_phase = 0; + if (--max == 0) + return; clean_up_insns(ep); if (repeat_phase & REPEAT_CFG_CLEANUP) kill_unreachable_bbs(ep);