This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, PR68337] Don't fold memcpy/memmove we want to instrument
- From: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Bernd Schmidt <bschmidt at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 23 Nov 2015 14:33:02 +0300
- Subject: Re: [PATCH, PR68337] Don't fold memcpy/memmove we want to instrument
- Authentication-results: sourceware.org; auth=none
- References: <20151119163110 dot GG42296 at msticlxl57 dot ims dot intel dot com> <564E02FE dot 5020503 at redhat dot com> <BBF11FD1-3884-4D6A-8FF7-7F4A658B5DBF at gmail dot com> <20151120130827 dot GH42296 at msticlxl57 dot ims dot intel dot com> <CAFiYyc3F=-hD_zkWSY51wv0t2OQRYvJwzK4VS8Hp-Cbs3cP1og at mail dot gmail dot com> <20151120143020 dot GI42296 at msticlxl57 dot ims dot intel dot com> <CAFiYyc1SoGMuDjdr02HxRqQkFc7CV-nf4+u9xoa2icr5vd_BTg at mail dot gmail dot com> <20151123101013 dot GA11184 at msticlxl57 dot ims dot intel dot com> <CAFiYyc0xcT6cKPo6YnB0ysEhKCxWmfMrh=WcCXA6rKHi9od1NQ at mail dot gmail dot com>
On 23 Nov 11:44, Richard Biener wrote:
> On Mon, Nov 23, 2015 at 11:10 AM, Ilya Enkovich <enkovich.gnu@gmail.com> wrote:
> > On 23 Nov 10:39, Richard Biener wrote:
> >> On Fri, Nov 20, 2015 at 3:30 PM, Ilya Enkovich <enkovich.gnu@gmail.com> 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?
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.
> >> >>