From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109099 invoked by alias); 23 Nov 2015 13:29:04 -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 109080 invoked by uid 89); 23 Nov 2015 13:29:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f176.google.com Received: from mail-yk0-f176.google.com (HELO mail-yk0-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 23 Nov 2015 13:29:02 +0000 Received: by ykfs79 with SMTP id s79so237664033ykf.1 for ; Mon, 23 Nov 2015 05:29:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.40.147 with SMTP id o141mr13281960ywo.305.1448285340191; Mon, 23 Nov 2015 05:29:00 -0800 (PST) Received: by 10.37.93.11 with HTTP; Mon, 23 Nov 2015 05:29:00 -0800 (PST) In-Reply-To: <20151123113302.GB11184@msticlxl57.ims.intel.com> References: <20151119163110.GG42296@msticlxl57.ims.intel.com> <564E02FE.5020503@redhat.com> <20151120130827.GH42296@msticlxl57.ims.intel.com> <20151120143020.GI42296@msticlxl57.ims.intel.com> <20151123101013.GA11184@msticlxl57.ims.intel.com> <20151123113302.GB11184@msticlxl57.ims.intel.com> Date: Mon, 23 Nov 2015 13:31:00 -0000 Message-ID: Subject: Re: [PATCH, PR68337] Don't fold memcpy/memmove we want to instrument From: Richard Biener To: Ilya Enkovich Cc: Bernd Schmidt , GCC Patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02710.txt.bz2 On Mon, Nov 23, 2015 at 12:33 PM, Ilya Enkovich wrote: > On 23 Nov 11:44, Richard Biener wrote: >> On Mon, Nov 23, 2015 at 11:10 AM, Ilya Enkovich wrote: >> > On 23 Nov 10:39, Richard Biener wrote: >> >> On Fri, Nov 20, 2015 at 3:30 PM, Ilya Enkovich wrote: >> >> > On 20 Nov 14:54, Richard Biener wrote: >> >> >> >> >> >> I don't think you can in any way rely on the pointer type of the src argument >> >> >> as all pointer conversions are useless and memcpy and friends take void * >> >> >> anyway. >> >> > >> >> > This check is looking for cases when we have type information indicating >> >> > no pointers are copied. In case of 'void *' we have to assume pointers >> >> > are copied and inlining is undesired. Test pr68337-2.c checks pointer >> >> > type allows to enable inlining. Looks like this check misses >> >> > || !COMPLETE_TYPE_P(TREE_TYPE (TREE_TYPE (src)))? >> >> >> >> As said there is no information in the pointer / pointed-to type in GIMPLE. >> > >> > What does it mean? We do have TREE_TYPE for used pointer and nested TREE_TYPE >> > holding pointed-to type. Is it some random invalid type? >> >> Yes, it can be a "random" type. Like for >> >> void foo (float *f) >> { >> memcpy ((void *)f, ...); >> } >> int main() >> { >> int **a[10]; >> foo (a); >> } >> >> which tries to copy to an array of int * but the GIMPLE IL for foo >> will call memcpy with a float * typed argument. > > I see. But it should still be OK to check type in case of strict aliasing, right? No, memcpy is always "no-strict-aliasing" > Thanks, > Ilya > >> >> >> >> >> >> >> >> >> Note that you also disable memmove to memcpy simplification with this >> >> >> early check. >> >> > >> >> > Doesn't matter for MPX which uses the same implementation for both cases. >> >> > >> >> >> >> >> >> Where is pointer transfer handled for MPX? I suppose it's not done >> >> >> transparently >> >> >> for all memory move instructions but explicitely by instrumented block copy >> >> >> routines in libmpx? In which case how does that identify pointers vs. >> >> >> non-pointers? >> >> > >> >> > It is handled by instrumentation pass. Compiler checks type of stored data to >> >> > find pointer stores. Each pointer store is instrumented with bndstx call. >> >> >> >> How does it identify "pointer store"? With -fno-strict-aliasing you can store >> >> pointers using an integer type. You can also always store pointers using >> >> a character type like >> >> >> >> void foo (int *p, int **dest) >> >> { >> >> ((char *)*dest)[0] = (((char *)&p)[0]; >> >> ((char *)*dest)[1] = (((char *)&p)[1]; >> >> ((char *)*dest)[2] = (((char *)&p)[2]; >> >> ((char *)*dest)[3] = (((char *)&p)[3]; >> >> } >> > >> > Pointer store is identified using type information. When pointer is casted to >> > a non-pointer type its bounds are lost. >> > >> > Ilya >> > >> >> >> >> > MPX versions of memcpy, memmove etc. don't make any assumptions about >> >> > type of copied data and just copy whole chunk of bounds metadata corresponding >> >> > to copied block. >> >> >> >> So it handles copying a pointer in two pieces with two memcpy calls >> >> correctly. Good. >> >> >> >> Richard. >> >> >> >> > Thanks, >> >> > Ilya >> >> > >> >> >> >> >> >> Richard. >> >> >>