> On Wed, 20 Apr 2011, Jan Hubicka wrote:
>
> > > Hi,
> > >
> > > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote:
> > > > Actually what happens here is that CCP devirtualize by propagating the
> > > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we
> > > > finally
Hi,
On Wed, Apr 20, 2011 at 04:38:25PM +0200, Jan Hubicka wrote:
> > Hi,
> >
> > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote:
> > > Actually what happens here is that CCP devirtualize by propagating the
> > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we
> >
On Wed, 20 Apr 2011, Jan Hubicka wrote:
> > Hi,
> >
> > On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote:
> > > Actually what happens here is that CCP devirtualize by propagating the
> > > constructors and due to Richard's new code to drop OBJ_TYPE_REF we
> > > finally get
> > > a dir
> Hi,
>
> On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote:
> > Actually what happens here is that CCP devirtualize by propagating the
> > constructors and due to Richard's new code to drop OBJ_TYPE_REF we finally
> > get
> > a direct call. This is all good and desirable.
> >
> > I t
Hi,
On Tue, Apr 19, 2011 at 02:15:18AM +0200, Jan Hubicka wrote:
> Actually what happens here is that CCP devirtualize by propagating the
> constructors and due to Richard's new code to drop OBJ_TYPE_REF we finally get
> a direct call. This is all good and desirable.
>
> I think good solution wo
Hi,
On Tue, Apr 19, 2011 at 09:07:35AM +0200, Jakub Jelinek wrote:
> On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
> > On 04/18/2011 02:40 PM, Jakub Jelinek wrote:
> > >If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> > >adjusted, but none of the callers are pr
On 04/19/2011 12:07 AM, Jakub Jelinek wrote:
On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
Well, it means that we do dynamic adjustment at runtime. If we're
able to do devirtualization, we should be able to figure out the
right offset as well, just not in 4.6.
Sure, but how
Hi,
>
> Well, even for the partial inlining case I'd devise a scheme that
> if a call to such a forwarder remains it gets expanded as a call to
> the original (non-split) function (similar to emitting a call to
> the asm-thunk instead of expanding the gimple representation of the
> thunk). I rea
On Tue, 19 Apr 2011, Jan Hubicka wrote:
> > I thought the idea was to use __builtin_va_arg_pack and friends.
> > Of course the inliner would still need to know how to inline such
> > a va-arg forwarder, and we would need a way to expand them (well,
> > or just go the existing special casing). We
> I thought the idea was to use __builtin_va_arg_pack and friends.
> Of course the inliner would still need to know how to inline such
> a va-arg forwarder, and we would need a way to expand them (well,
> or just go the existing special casing). We might need this
> kind of inliner support anyway
On Tue, 19 Apr 2011, Jan Hubicka wrote:
> > On Tue, 19 Apr 2011, Jan Hubicka wrote:
> >
> > > > Huh. No, I don't think we want to do any "inlining" as part of
> > > > folding. At least not if it
> > > > is a correctness issue (is it?). Why does the inliner not simply
> > > > inline the thunk f
> On Tue, 19 Apr 2011, Jan Hubicka wrote:
>
> > > Huh. No, I don't think we want to do any "inlining" as part of
> > > folding. At least not if it
> > > is a correctness issue (is it?). Why does the inliner not simply
> > > inline the thunk function
> > > body?
> >
> > Because thunk functions
On Tue, 19 Apr 2011, Jan Hubicka wrote:
> > Huh. No, I don't think we want to do any "inlining" as part of
> > folding. At least not if it
> > is a correctness issue (is it?). Why does the inliner not simply
> > inline the thunk function
> > body?
>
> Because thunk functions have no bodies in
> Huh. No, I don't think we want to do any "inlining" as part of
> folding. At least not if it
> is a correctness issue (is it?). Why does the inliner not simply
> inline the thunk function
> body?
Because thunk functions have no bodies in gimple form and are no functions (at
the moment) in cgr
On Tue, Apr 19, 2011 at 2:15 AM, Jan Hubicka wrote:
>> > Hi!
>> >
>> > If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
>> > adjusted, but none of the callers are prepared to handle that.
>> > Thus, this patch makes devirtualization give up in those cases.
>> >
>> > Bootstrapped/
On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
> On 04/18/2011 02:40 PM, Jakub Jelinek wrote:
> >If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> >adjusted, but none of the callers are prepared to handle that.
>
> Well, it means that we do dynamic adjustment at
> > Hi!
> >
> > If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> > adjusted, but none of the callers are prepared to handle that.
> > Thus, this patch makes devirtualization give up in those cases.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, trunk and 4.6.
>
> Hi!
>
> If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> adjusted, but none of the callers are prepared to handle that.
> Thus, this patch makes devirtualization give up in those cases.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, trunk and 4.6.
> On the trunk
On Mon, Apr 18, 2011 at 2:40 PM, Jakub Jelinek wrote:
> Hi!
>
> If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> adjusted, but none of the callers are prepared to handle that.
> Thus, this patch makes devirtualization give up in those cases.
>
> Bootstrapped/regtested on x86_64
On 04/18/2011 02:40 PM, Jakub Jelinek wrote:
If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
adjusted, but none of the callers are prepared to handle that.
Well, it means that we do dynamic adjustment at runtime. If we're able
to do devirtualization, we should be able to fi
On Mon, Apr 18, 2011 at 11:40 PM, Jakub Jelinek wrote:
> Hi!
>
> If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> adjusted, but none of the callers are prepared to handle that.
> Thus, this patch makes devirtualization give up in those cases.
>
> Bootstrapped/regtested on x86_6
Hi!
If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
adjusted, but none of the callers are prepared to handle that.
Thus, this patch makes devirtualization give up in those cases.
Bootstrapped/regtested on x86_64-linux and i686-linux, trunk and 4.6.
On the trunk the testcase ICE
22 matches
Mail list logo
