On Mon, Nov 23, 2015 at 12:33 PM, Ilya Enkovich <enkovich....@gmail.com> wrote:
> On 23 Nov 11:44, Richard Biener wrote:
>> On Mon, Nov 23, 2015 at 11:10 AM, Ilya Enkovich <enkovich....@gmail.com>
>> wrote:
>> > On 23 Nov 10:39, Richard Biener wrote:
>> >> On Fri, Nov 20, 2015 at 3:30 PM, Ilya Enkovich <enkovich....@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?
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.
>> >> >>
