From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20030 invoked by alias); 2 May 2014 14:06:26 -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 19995 invoked by uid 48); 2 May 2014 14:06:23 -0000 From: "glisse at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/59948] Optimize std::function Date: Fri, 02 May 2014 14:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: glisse at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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: 2014-05/txt/msg00074.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59948 --- Comment #5 from Marc Glisse --- (In reply to Jan Hubicka from comment #3) > The code in fold-const for nonzero check is really broken. I have somewerhe > WIP symtab patch for doing this, but it is not completely trivial to hook it > into fold-const when symtab is not built yet - just as in this case and in > some cases for LTO you really want to know if symbol is defined... For this case I don't think you really need to do it in fold-const, it should be fine to handle it elsewhere later (VRP may not be enough though), or to do it in fold-const but skip it if symtab is not ready. But if LTO has stronger requirements... (In reply to Jan Hubicka from comment #4) > About the inlining issue, am not really sure how to handle this without > iterating optimizers and inliner like llvm does (Maxim had patch for this). > I wonder if we can't just declare the operator () always_inline to make sure > it is early inlined? I'd rather avoid relying on always_inline, so it still works if people use boost::function or other similar code instead. But maybe temporarily... > It gets me to _M_empty call that we fail to inline because we do not inline > into alwaysinlines (because of cycles) but then we do not iterate the early > inliner anymore so we do not inline after inlining always inlines. This is > quite broken :( Any news on Maxim's patch? There was a discussion in 2011, but I can't find anything more recent, and things have changed a bit since then...