From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28481 invoked by alias); 20 Feb 2015 07:59:49 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 28419 invoked by uid 48); 20 Feb 2015 07:59:44 -0000 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/64374] [5 Regression] LTO ICE in extract_insn, at recog.c:2327 Date: Fri, 20 Feb 2015 07:59:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-02/txt/msg02214.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64374 --- Comment #10 from Jakub Jelinek --- I see another issue. When we stream in OPTIMIZATION_NODE/TARGET_OPTIONS_NODE, we don't use build_optimization_node/build_target_option_node and thus we don't merge identical nodes by hashing them together in between different streamed in TUs (or does it happen somehow else)? If it doesn't happen, then it unnecessarily slows down lto1, because it needs to reinitialize the backend more often and switch in between different target options even when they are effectively the same. Though, of course, if we'd hash them together, we'd need to call some target hook to resync the streamed in options with the global state before hashing them together, because they can't be changed while they are in the hash table.