From patchwork Sun Sep 24 13:06:23 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?J=C3=B8rgen_Kvalsvik?= X-Patchwork-Id: 1838680 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (4096-bit key; secure) header.d=kolabnow.com header.i=@kolabnow.com header.a=rsa-sha256 header.s=dkim20160331 header.b=fzZxd+sN; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4RtmYq5S2jz1ynF for ; Sun, 24 Sep 2023 23:09:33 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E2F2C3856972 for ; Sun, 24 Sep 2023 13:09:30 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx.kolabnow.com (mx.kolabnow.com [212.103.80.155]) by sourceware.org (Postfix) with ESMTPS id 4B45C3858C66 for ; Sun, 24 Sep 2023 13:09:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B45C3858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=lambda.is Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lambda.is Received: from localhost (unknown [127.0.0.1]) by mx.kolabnow.com (Postfix) with ESMTP id 35CFD2096F1A for ; Sun, 24 Sep 2023 15:06:59 +0200 (CEST) Authentication-Results: ext-mx-out011.mykolab.com (amavis); dkim=pass (4096-bit key) reason="pass (just generated, assumed good)" header.d=kolabnow.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:subject:subject:from:from:received :received:received; s=dkim20160331; t=1695560817; x=1697375218; bh=O50yC0CltcxxhaAONr4USWkvQ5lgs1EwuqOwbnz6UIA=; b=fzZxd+sNx4hy 8JMvCkYmUFKc1e+2stGh/VpLAqgNFYvsk7h3HIdSVbdOpcee+rA0YRCDstJ0JrcQ 6iKZvh4cebK9Hf263UjZxrm6Z+Skovp5I0bnIM+4TTc5135rn0E8rozHddjcUDOK 2HvYm8YRnI5jCiK92tYn1waxruSgu/rTNh8oq/t9jxFdDXKcvJu9ItmnntwkAbjB Ee010PjimVDx4HBnj8j1btzYKfK67kiQv7uCplqFVvBt8kglOB3j5QbKegfrWxS/ W/KCU3CFL+VjWrMlWyWWa+aLEcBA8me+2j9ozDwM6YKDfDpMJRLHUrNZUwFXTpXq K6SpuSwYaw9z6A6viUVrUJ1YYikVnQBM/MwKphyAGPwm7BmFh/AsbQUYcUzPhWYb bNsDgv/ldsG1p+Ej1CB/QNB8JMOk7bd5y8mSsVAZoYqXee/i1WKHTvKupPYOgTiK 5IfGR1dJH8wtUlsRXNZ1t/+H+n53M5VQ+yEqiGC3KYMVkEIQFrGA3Z47sV2u119u 5RfjbF2Hf3U22pe2+xvoPcxbxFUQ0fc+fjbPtIWpy0w28t/74LJY10+4aUxhdWs5 YbnjIxz44wCmyng7qJObs4IvbPfAeKgn+xT6YdzgtlrQ9pkFhsp1ZUK93gaKY703 ZGomV/Gfx0VRj+g9/wJwT0Fl8LymaM4= X-Virus-Scanned: amavis at mykolab.com X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-11.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out011.mykolab.com [127.0.0.1]) (amavis, port 10024) with ESMTP id ZxYgNQC5WB5M for ; Sun, 24 Sep 2023 15:06:57 +0200 (CEST) Received: from int-mx009.mykolab.com (unknown [10.9.13.9]) by mx.kolabnow.com (Postfix) with ESMTPS id BDDAF2096F07 for ; Sun, 24 Sep 2023 15:06:57 +0200 (CEST) Received: from ext-subm010.mykolab.com (unknown [10.9.6.10]) by int-mx009.mykolab.com (Postfix) with ESMTPS id 54A1C20D1498 for ; Sun, 24 Sep 2023 15:06:57 +0200 (CEST) From: =?utf-8?q?J=C3=B8rgen_Kvalsvik?= To: gcc-patches@gcc.gnu.org Cc: =?utf-8?q?J=C3=B8rgen_Kvalsvik?= Subject: [PATCH] Always generate else-block in gimplify Date: Sun, 24 Sep 2023 22:06:23 +0900 Message-Id: <20230924130623.2112322-1-j@lambda.is> MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org This is a request for feedback and a proof-of-concept, not something I intend to merge as-is. It would be nice if gcc, maybe just under some circumstances, always generated an else-block for coverage purposes. I am working on the MC/DC support by CFG analysis for a while https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621449.html and have ironed out a lot of problems. The last problem I know about, which is impossible to actually fix right now, is the "fusing" of nested ifs. Here is an example: if (a) if (b) if (c) { ... } // 3 conditions, 6 outcomes if (a && b && c) { ... } // 3 conditions, 6 outcomes These form isomorphic CFGs which means there is no way for my algorithm to distinguish them. This is sort-of acceptable since the coverage measurements more accurately measure the semantics (and not the syntax), but this also happens when there is code in-between the nesting: if (a) // measures to 2 conditions, 4 outcomes { a += b * 10; b -= a + 2; if (b) { ... } } You would expect this to be measured as: if (a) // 1 condition, 2 outcomes { a += b * 10; b -= a + 2; if (b) // 1 condition, 2 outcomes { ... } } The source of the problem is the missing (or empty) else block, as the algorithm uses the outcome (then/else) edges to determine the limits of expressions. If, however, the else blocks are generated, the conditions are counted as you would expect. So I have a few questions: 1. Is something like this even acceptable? The semantics of the program should not change, assuming the else-block only exists but is without significant behavior. It will only be generated if there is no explicit else in source. 2. Should this only be generated when necessary (e.g. under condition coverage? No optimization?) 3. I used a simple int-init { int __mcdc_barrier = 0; } but there might be better contents for the block that does not add anything operationally. I am not very familiar with this part of gcc and would like to see someting better. Any suggestions? --- gcc/gimplify.cc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc index ade6e335da7..43af38df742 100644 --- a/gcc/gimplify.cc +++ b/gcc/gimplify.cc @@ -4370,6 +4370,14 @@ gimplify_cond_expr (tree *expr_p, gimple_seq *pre_p, fallback_t fallback) enum tree_code pred_code; gimple_seq seq = NULL; + if (TREE_OPERAND (expr, 2) == NULL_TREE) + { + tree var = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifier + ("__mcdc_barrier"), integer_type_node); + tree val = build_int_cst (integer_type_node, 0); + TREE_OPERAND (expr, 2) = build2 (INIT_EXPR, TREE_TYPE (var), var, val); + } + /* If this COND_EXPR has a value, copy the values into a temporary within the arms. */ if (!VOID_TYPE_P (type))