From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 27B2B3858C5E; Wed, 22 Feb 2023 19:48:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 27B2B3858C5E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1677095310; bh=MeK5lZpqvZ0/+Crcwn+7VQobyIa49ROPIx4sCrw5NQU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ouAgjxUUAi483NfM3yYYziMDIYammfRYaA4Ic065t7TSmZJpCwxMBHJXWsUf6zx8R xOke57ycd6i6YXfiTKMLVEQ2atSfBWG2daUcaDheqGlDXLGVe3qty3YE2FP4NeVARD ovCaDMYCfzHeIS1scKau3pRqmPHJ58utAMDjv+X0= From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/108880] [11/12/13 Regression] slow compilation with "-fsanitize=undefined" Date: Wed, 22 Feb 2023 19:48:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: compile-time-hog X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.4 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D108880 --- Comment #9 from Jakub Jelinek --- (In reply to Richard Biener from comment #4) > It's not only "slow", it also produces a gigantic executable, the .origin= al > dump was 7.1GB when I stopped the compilation ... Well, original dump for deeply nested SAVE_EXPRs is pretty unusable, even w= hen the actual trees are fairly small, because it prints each SAVE_EXPR in full. If we wanted to avoid that, we'd need to use during the printing some hash table on which SAVE_EXPRs we have printed already and print some id for them and print just that id rather than full content next time we see it. Or perhaps trigger that behavior when we see deeper SAVE_EXPR nesting. > The culprit is c_genericize calling c_genericize_control_r which must > somehow do the ubsan instrumentation as well. As Marek said, on the C++ FE side this is handled by cp-gimplify.cc using a pset on its own and not trying to genericize a control stmt which has been handled already (e.g. when seeing it again in another SAVE_EXPR), or even SAVE_EXPRs that have been handled already. So, adding another pset that would be used also for C++ would be a waste. Now, the C FE in c-gimplify.cc has: walk_tree_without_duplicates (&DECL_SAVED_TREE (fndecl), c_genericize_control_r, NULL); so it effectively already creates a pset. Thus, I think we should replace this walk_tree_without_duplicates with a new pset + walk_tree, pass &pset twice - as pset and data and in c_genericize_control_r don't walk again what we've already walked. which=