On 07/23/2014 07:29 AM, Richard Biener wrote:
On Wed, Jul 23, 2014 at 12:44 PM, Jason Merrill wrote:
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object via the pointer
On Thu, Jul 24, 2014 at 12:46 PM, Jan Hubicka wrote:
>>
>> Aggregate copies and memcpy transferring the dynamic type for example.
>> Being able to tbaa union accesses for another. And yes, placement new.
>
> I see that if we previously dropped all union accesses to 0, the current
> scheme
> is
>
> Aggregate copies and memcpy transferring the dynamic type for example. Being
> able to tbaa union accesses for another. And yes, placement new.
I see that if we previously dropped all union accesses to 0, the current scheme
is nice improvement. But it seem to me it may be in use only when
On Thu, Jul 24, 2014 at 11:53 AM, Richard Biener
wrote:
> On Thu, Jul 24, 2014 at 11:23 AM, Jan Hubicka wrote:
>>> > *shortptr = exp
>>> >
>>> > var = *shortptr
>>> > *intptr = exp
>>> >
>>> > var = *intptr
>>>
>>> Yes (that is, you can't hoist the *intptr = exp store above the var =
>>>
On Thu, Jul 24, 2014 at 11:23 AM, Jan Hubicka wrote:
>> > *shortptr = exp
>> >
>> > var = *shortptr
>> > *intptr = exp
>> >
>> > var = *intptr
>>
>> Yes (that is, you can't hoist the *intptr = exp store above the var =
>> *shortptr
>> load with TBAA only). You can probably still hoist th
> > *shortptr = exp
> >
> > var = *shortptr
> > *intptr = exp
> >
> > var = *intptr
>
> Yes (that is, you can't hoist the *intptr = exp store above the var =
> *shortptr
> load with TBAA only). You can probably still hoist the chain with intptr>, it's not clear from your example.
Well,
On Wed, Jul 23, 2014 at 6:29 PM, Jan Hubicka wrote:
>> On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
>> >> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> >> >> I don't see why
>> >> >>
>> >> >> long x[1024];
>> >> >>
>> >> >> Q *q = new (x) Q;
>> >> >> q->~Q ();
>> >> >> new (x) T
> On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
> >> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
> >> >> I don't see why
> >> >>
> >> >> long x[1024];
> >> >>
> >> >> Q *q = new (x) Q;
> >> >> q->~Q ();
> >> >> new (x) T;
> >> >>
> >> >> would be invalid. I also don't see why
> >>
On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
>> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> >> I don't see why
>> >>
>> >> long x[1024];
>> >>
>> >> Q *q = new (x) Q;
>> >> q->~Q ();
>> >> new (x) T;
>> >>
>> >> would be invalid. I also don't see why
>> >>
>> >> Q q;
>> >> q.~
> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
> >> I don't see why
> >>
> >> long x[1024];
> >>
> >> Q *q = new (x) Q;
> >> q->~Q ();
> >> new (x) T;
> >>
> >> would be invalid. I also don't see why
> >>
> >> Q q;
> >> q.~Q ();
> >> new (&q) T;
> >>
> >> would be. Object lifetime is prec
On Wed, Jul 23, 2014 at 12:44 PM, Jason Merrill wrote:
> On 07/22/2014 02:34 PM, Richard Biener wrote:
>>
>> As discussed during the Cauldron keeping some builtin doesn't help because
>>
>> you are not forced to access the newly created object via the pointer
>> returned
>> by the placement new.
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object via the pointer returned
by the placement new. That is,
template
struct Storage {
char x[sizeof(T)];
St
On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> I don't see why
>>
>> long x[1024];
>>
>> Q *q = new (x) Q;
>> q->~Q ();
>> new (x) T;
>>
>> would be invalid. I also don't see why
>>
>> Q q;
>> q.~Q ();
>> new (&q) T;
>>
>> would be. Object lifetime is precisely specified and I don't see
> I don't see why
>
> long x[1024];
>
> Q *q = new (x) Q;
> q->~Q ();
> new (x) T;
>
> would be invalid. I also don't see why
>
> Q q;
> q.~Q ();
> new (&q) T;
>
> would be. Object lifetime is precisely specified and I don't see where it is
> tied to (static) storage lifetime.
This is preci
On Tue, Jul 22, 2014 at 3:54 PM, Jan Hubicka wrote:
>>
>> As discussen during the Cauldron keeping some builtin doesn't help because
>> you are not forced to access the newly created object via the pointer
>> returned
>> by the placement new. That is,
>>
>> template
>> struct Storage {
>>
>
> As discussen during the Cauldron keeping some builtin doesn't help because
> you are not forced to access the newly created object via the pointer returned
> by the placement new. That is,
>
> template
> struct Storage {
> char x[sizeof(T)];
> Storage() { new (x) T; }
> T& g
On Sat, Jul 19, 2014 at 5:44 PM, Jan Hubicka wrote:
>> On 07/18/2014 11:03 AM, Jan Hubicka wrote:
>> >I really only care about types containing virtual table pointers to not
>> >change,
>> >so non-PODs are out of game. Current propagation is built around
>> >assumption that
>> >once polymorphic
> On 07/18/2014 11:03 AM, Jan Hubicka wrote:
> >I really only care about types containing virtual table pointers to not
> >change,
> >so non-PODs are out of game. Current propagation is built around assumption
> >that
> >once polymorphic type is constructed on a given location it won't change to
On 07/18/2014 11:03 AM, Jan Hubicka wrote:
I really only care about types containing virtual table pointers to not change,
so non-PODs are out of game. Current propagation is built around assumption
that
once polymorphic type is constructed on a given location it won't change to
completely diff
> On 07/08/2014 02:50 PM, Jan Hubicka wrote:
> >I am looking into tracking dynamic types now. Obviously I need to set very
> >exact rules about when these may change.
>
> Let me first say that this area is somewhat in flux in the standard;
> if we have a model of what we want the rules to be for G
On 07/08/2014 02:50 PM, Jan Hubicka wrote:
I am looking into tracking dynamic types now. Obviously I need to set very
exact rules about when these may change.
Let me first say that this area is somewhat in flux in the standard; if
we have a model of what we want the rules to be for GCC, there'
> > On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> > >We propagate types from places we know instances are created across
> > >pointers
> > >passed to functions. Once non-POD type is created at a given memory
> > >location,
> > >one can not change its type by placement_new into something else.
> >
On Thu, Jul 3, 2014 at 4:20 AM, Jason Merrill wrote:
> On 07/02/2014 06:30 PM, Jan Hubicka wrote:
>>
>> But this is one of things that was not quite clear to me. I know that
>> polymorphic type A
>> was created at a give memory location. THis means that accesses to that
>> location in one
>> ali
On Tue, Jul 8, 2014 at 2:50 PM, Jan Hubicka wrote:
>> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
>> >We propagate types from places we know instances are created across pointers
>> >passed to functions. Once non-POD type is created at a given memory
>> >location,
>> >one can not change its type
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the m
Jan Hubicka writes:
> Index: testsuite/g++.dg/ipa/imm-devirt-2.C
> ===
> --- testsuite/g++.dg/ipa/imm-devirt-2.C (revision 212278)
> +++ testsuite/g++.dg/ipa/imm-devirt-2.C (working copy)
> @@ -1,7 +1,7 @@
> /* Verify th
Jan Hubicka writes:
> * cgraph.c (cgraph_create_indirect_edge): Update call of
> get_polymorphic_call_info.
> * ipa-utils.h (get_polymorphic_call_info): Add parameter CALL.
> (possible_polymorphic_call_targets): Add parameter call.
> (decl_maybe_in_construction_p): N
> I'm fixing that with the following (will commit as obvious).
Marek,
With your patch g++.dg/ipa/imm-devirt-2.C sitll fails in 32 bit mode
because the mangling is C::_ZThn16_N1C3fooEi. This is fixed by something
such as
--- ../_clean/gcc/testsuite/g++.dg/ipa/imm-devirt-2.C 2014-07-05
23:22:5
On Fri, Jul 04, 2014 at 11:39:52PM +0200, Jan Hubicka wrote:
> Bootstrapped/regtested x86_64-linux, will commit it after bit more
> testing.
...
> * g++.dg/ipa/imm-devirt-1.C: Update testcase.
> * g++.dg/ipa/imm-devirt-2.C: Update testcase.
These testcases fail:
ERROR: g++.dg/ipa/imm-
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the m
> On 07/02/2014 06:30 PM, Jan Hubicka wrote:
> >But this is one of things that was not quite clear to me. I know that
> >polymorphic type A
> >was created at a give memory location. THis means that accesses to that
> >location in one
> >alias class has been made.
> >Now I destroy A and turn it
On 07/02/2014 06:30 PM, Jan Hubicka wrote:
But this is one of things that was not quite clear to me. I know that
polymorphic type A
was created at a give memory location. THis means that accesses to that
location in one
alias class has been made.
Now I destroy A and turn it into B, construct
> > On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> > >We propagate types from places we know instances are created across
> > >pointers
> > >passed to functions. Once non-POD type is created at a given memory
> > >location,
> > >one can not change its type by placement_new into something else.
> >
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the m
On 07/02/2014 01:18 PM, Jan Hubicka wrote:
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placement_new into something else.
Hmm. If the memory location i
Hi,
this patch strengthens detect_type_change and makes it cheaper based on the
following observation.
We propagate types from places we know instances are created across pointers
passed to functions. Once non-POD type is created at a given memory location,
one can not change its type by placeme
36 matches
Mail list logo
