From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (unknown [217.65.15.62]) by sourceware.org (Postfix) with ESMTPS id C4C103A35470 for ; Mon, 13 Nov 2023 14:29:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4C103A35470 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=ispras.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C4C103A35470 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.65.15.62 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699885801; cv=none; b=F+ZYfNB1fwMLQtnZGSzMbl+O8ppRsUlyjWaOEUVj5BeqLGuq32qfom0Zsq3dkKxkY/mwO3TQHc0fJ4GQMe6iD3RVuUSxog9BWAQWH4UplgkKfekPJgiGAVusGhUIQs3zVhtM8li41KCHdpPuMWYMlzpZ4SCdjlWohChpXKRSUuQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699885801; c=relaxed/simple; bh=Y/KPQCnuwCUOIUb9X9M7dGZLZ6i/TXqQCFVwOhjzLu8=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=ACB2N1EOa5bwGtialyahy2/WokenGDdUUz4fH+X68Y2A6EhhnThObguMc+PCdsbhIDMgpfLG9vk81twC+8X3HyjOgANfgIPc90QLLrtwo69zbahN8+tFmzhn3smYKKCGJ4UrU/AQk3OyPjwuXjpOw0ID6XiysZBjCDXmpucdQpg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id 365EA40F1DFE; Mon, 13 Nov 2023 14:29:49 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 365EA40F1DFE Date: Mon, 13 Nov 2023 17:29:49 +0300 (MSK) From: Alexander Monakov To: Richard Biener cc: exactlywb@ispras.ru, gcc-patches@gcc.gnu.org Subject: Re: [RFC PATCH] Detecting lifetime-dse issues via Valgrind In-Reply-To: Message-ID: References: <20231024141124.210708-1-exactlywb@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,TXREP,T_SCC_BODY_TEXT_LINE,T_SPF_HELO_TEMPERROR,T_SPF_TEMPERROR autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 13 Nov 2023, Richard Biener wrote: > Another generic comment - placing a built-in call probably pessimizes code > generation unless we handle it specially during alias analysis (or in > builtin_fnspec). But considering the resulting code is intended to be run under Valgrind, isn't a bit worse quality acceptable? Note that we don't want loads following the built-in to be optimized out, they are necessary as they will be flagged by Valgrind as attempts to read uninitialized memory. I suspect positioning the pass immediately after build_ssa as we do now is quite imperfect because we will then instrument 'x' in void f() { int x, *p; p = &x; } Ideally we'd position it such that more locals are put in SSA form, but not too late to miss some UB, right? Perhaps after first pass_ccp? > I also don't like having another pass for this - did you > investigate to do the instrumentation at the point the CLOBBERs are > introduced? I don't see a better approach, some CLOBBERs are emitted by the C++ front-end via build_clobber_this, some by omp-expand, some during gimplification. I'm not a fan of useless IR rescans either, but this pass is supposed to run very rarely, not by default. > Another possibility would be to make this more generic > and emit the instrumentation when we lower GIMPLE_BIND during > the GIMPLE lowering pass, you wouldn't then rely on the CLOBBERs > some of which only appear when -fstack-reuse=none is not used. The CLOBBERs that trigger on Firefox and LLVM are emitted not during gimplification, but via build_clobber_this in the front-end. Alexander