On Tue, Sep 3, 2013 at 3:42 PM, Jan Hubicka wrote:
>> > The decision what should go to local or global stream is basically
>> > motivated by
>> > 1) everything needed for interprocedural optimization has to be global
>> > 2) everything related to function bodies should be local.
>>
>> I'd rat
> > The decision what should go to local or global stream is basically
> > motivated by
> > 1) everything needed for interprocedural optimization has to be global
> > 2) everything related to function bodies should be local.
>
> I'd rather formulate it as "everything not needed at WPA time sh
On Mon, Sep 2, 2013 at 5:19 PM, Jan Hubicka wrote:
>>
>> But we still refer to the local entity from TREE_TYPE of the function decl,
>> no?
>
> depending on definition of local entity. I tought we was discussing if
> PARM_DECL
> is local or not.
>
> I spent some time thining about the whole stre
Hi,
also to avoid the ICE in the original testcase, we do not really need the
DECL_ARGUMENTS/RESULT_DECL lists. All we need is RESULT_DECL in the global
stream. The following one liner fixes the testcase and all variants of my
ulitimate death testcase that did not ICE in tree from beggining of Au
Hi,
the following testcase illustrate problem with the offset. Sadly it ICEs even
w/o
LTO:
evans:/abuild/jh/trunk-3/build-inst12/gcc/:[1]# ./xgcc -B ./ -O2 ~/tt.c
/root/tt.c: In function 'main':
/root/tt.c:24:11: warning: overflow in implicit constant conversion [-Woverflow]
b.b=
>
> But we still refer to the local entity from TREE_TYPE of the function decl,
> no?
depending on definition of local entity. I tought we was discussing if
PARM_DECL
is local or not.
I spent some time thining about the whole streaming scheme and I think we do
have
important side cases handle
On Mon, Sep 2, 2013 at 3:02 PM, Jan Hubicka wrote:
>> >
>> > Well, there is still fallout from this change so I'm not convinced
>> > this will stay
>> > this way. Also we stream the function-decl that refers to these fields in
>>
>> As far as I know there are two problems
>> 1) problem with the
> >
> > Well, there is still fallout from this change so I'm not convinced
> > this will stay
> > this way. Also we stream the function-decl that refers to these fields in
>
> As far as I know there are two problems
> 1) problem with the thunk expansion not getting DECL_ARGUMENTS/DECL_RESULT
>
>
> Well, there is still fallout from this change so I'm not convinced
> this will stay
> this way. Also we stream the function-decl that refers to these fields in
As far as I know there are two problems
1) problem with the thunk expansion not getting DECL_ARGUMENTS/DECL_RESULT
addressed by
On Mon, Sep 2, 2013 at 1:43 PM, Jan Hubicka wrote:
>> > + tree a;
>> > +
>> > + if (in_lto_p)
>> > +cgraph_get_body (node);
>>
>> That looks gross. It cannot possibly be the correct fix for this.
> DECL_ARGUMENTS/DECL_RESULT are now part of function body.
Well, there is still fallout from
> > + tree a;
> > +
> > + if (in_lto_p)
> > +cgraph_get_body (node);
>
> That looks gross. It cannot possibly be the correct fix for this.
DECL_ARGUMENTS/DECL_RESULT are now part of function body. cgraph_get_body is
there to load it for you when you need it. We are going to expand the func
On Mon, Sep 2, 2013 at 12:52 PM, Jan Hubicka wrote:
>> On Aug 21, 2013, at 11:47 PM, Jan Hubicka wrote:
>> >> The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv)
>> >> is used during thunk code-generation, and thunk code-generation happens
>> >> during the output of D::foo.
> On Aug 21, 2013, at 11:47 PM, Jan Hubicka wrote:
> >> The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv)
> >> is used during thunk code-generation, and thunk code-generation happens
> >> during the output of D::foo.
>
> > I see, I will try to modify i386 backend to not o
On Aug 21, 2013, at 11:47 PM, Jan Hubicka wrote:
>> The problem is that DECL_ARGUMENTS of the thunk (aka _ZThn528_N1D3fooEv) is
>> used during thunk code-generation, and thunk code-generation happens during
>> the output of D::foo.
> I see, I will try to modify i386 backend to not output thunks
> So, I was tracking down an lto failure in the C++ test suite,
> g++.dg/ipa/pr46984.C, and it appears to be caused by
> 4df870fdeec85907db3dcabf1992cf8b63e1d562 aka
> svn+ssh://gcc.gnu.org/svn/gcc/trunk@201468. I was trying to find the
> gcc-patches email for this work, but could not. :-( A
On Aug 1, 2013, at 8:09 AM, Jan Hubicka wrote:
> Now when we have abstract origins tracked, this patch makes DECL_ARGUMENTS and
> DECL_RESULT to be removed from FUNCTION_DECLs that are never passed to symbol
> table. This reduces LTO streaming effort (by about 1/3rd of PARM_DECls)
So, I was trac
Hi,
Now when we have abstract origins tracked, this patch makes DECL_ARGUMENTS and
DECL_RESULT to be removed from FUNCTION_DECLs that are never passed to symbol
table. This reduces LTO streaming effort (by about 1/3rd of PARM_DECls)
Bootstrapped/regtested ppc64-linux, will commit it after further
17 matches
Mail list logo
