From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55141 invoked by alias); 22 Feb 2016 13:04:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 53843 invoked by uid 89); 22 Feb 2016 13:04:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=symbol_table, xxx X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 22 Feb 2016 13:04:52 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F0859AB9D; Mon, 22 Feb 2016 13:04:48 +0000 (UTC) Date: Mon, 22 Feb 2016 13:04:00 -0000 From: Richard Biener To: Jakub Jelinek cc: gcc-patches@gcc.gnu.org, Jan Hubicka Subject: Re: [PATCH] Fix PR56888 In-Reply-To: Message-ID: References: <20160222125418.GI3017@tucnak.redhat.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2016-02/txt/msg01457.txt.bz2 On Mon, 22 Feb 2016, Richard Biener wrote: > On Mon, 22 Feb 2016, Jakub Jelinek wrote: > > > On Mon, Feb 22, 2016 at 01:44:09PM +0100, Richard Biener wrote: > > > --- 1079,1086 ---- > > > || !dominated_by_p (CDI_DOMINATORS, > > > loop->latch, gimple_bb (stmt))) > > > return; > > > + if (cgraph_node::get (cfun->decl)->aliases (BUILT_IN_MEMSET)) > > > + return; > > > > Perhaps also punt here for: > > BUILT_IN_MEMSET_CHK > > BUILT_IN_TM_MEMSET > > BUILT_IN_BZERO > > ? > > > > > partition->kind = PKIND_MEMSET; > > > partition->main_dr = single_store; > > > partition->niter = nb_iter; > > > *************** classify_partition (loop_p loop, struct > > > *** 1135,1140 **** > > > --- 1138,1146 ---- > > > } > > > free_dependence_relation (ddr); > > > loops.release (); > > > + if (cgraph_node::get (cfun->decl)->aliases (BUILT_IN_MEMCPY) > > > + || cgraph_node::get (cfun->decl)->aliases (BUILT_IN_MEMMOVE)) > > > + return; > > > > And here for > > BUILT_IN_MEMCPY_CHK > > BUILT_IN_TM_MEMCPY > > BUILT_IN_TM_MEMCPY_RNWT > > BUILT_IN_TM_MEMCPY_RTWN > > BUILT_IN_MEMPCPY > > BUILT_IN_MEMPCPY_CHK > > BUILT_IN_MEMMOVE_CHK > > BUILT_IN_TM_MEMMOVE > > BUILT_IN_BCOPY > > ? > > I'm going to wait for Honzas feedback. Testing all of the above > looks expensive - if those are implemented in terms of memcpy/memset > then hopefully in libc itself which hopefully always does local > calls. > > It's not going to be an exhaustive check anyway, just a QOI one > covering those cases we've seen in the wild. Esp. as indirection > will break the detection (so does using asm(".alias XXX") which glibc > does). Ok, so maybe a better question to symtab would be if there is an actual definition for what __builtin_FOO will call. Not really whether that definition is cfun. Of course all the fortify always-inline wrappers should not count as such (just in case the symtab code is confused about those). So, bool symbol_table::have_definition (enum built_in_fn); ? Not sure how to best implement that either. asmname lookups are expensive ... Richard.