> Hi,
>
> On Thu, Sep 01, 2011 at 08:52:30PM +0200, Jan Hubicka wrote:
> > > - Nevertheless, this method of devirtualization cannot automatically
> > > de-thunkize this-adjusting thunks and newly direct calls to them
> > > cannot be inlined because the inliner does not have this capability
> >
Hi,
On Thu, Sep 01, 2011 at 08:52:30PM +0200, Jan Hubicka wrote:
> > - Nevertheless, this method of devirtualization cannot automatically
> > de-thunkize this-adjusting thunks and newly direct calls to them
> > cannot be inlined because the inliner does not have this capability
> > now. Thi
On Thu, Sep 1, 2011 at 8:52 PM, Jan Hubicka wrote:
>> - Nevertheless, this method of devirtualization cannot automatically
>> de-thunkize this-adjusting thunks and newly direct calls to them
>> cannot be inlined because the inliner does not have this capability
>> now. This is in fact a reg
> - Nevertheless, this method of devirtualization cannot automatically
> de-thunkize this-adjusting thunks and newly direct calls to them
> cannot be inlined because the inliner does not have this capability
> now. This is in fact a regression from 4.6, and testcases
> ivinline-7.C and ivi
Hi,
the patch below is an updated version of an RFC patch I have sent here
some three weeks ago:
http://gcc.gnu.org/ml/gcc-patches/2011-08/msg00975.html
However, this is no longer an RFC but a request for approval because I
have amended it to work also on architectures that use function
descript
Hi,
the patch below changes devirtualization to use BINFO_VTABLE instead
of BINFO_VIRTUALS. This is in fact slightly more cumbersome to use in
almost any respect but has one huge advantage, it uses _much_ less
memory in LTO, because the virtual tables are unified just like all
other VAR_DECLs and
