Revised as suggested and committed.
Thanks,
David
On Thu, Apr 21, 2011 at 1:36 PM, Jan Hubicka wrote:
>> @@ -730,6 +726,8 @@ void cgraph_clone_inlined_nodes (struct
>> void compute_inline_parameters (struct cgraph_node *);
>> cgraph_inline_failed_t cgraph_edge_inlinable_p (struct cgraph_edge
> On Thu, Apr 21, 2011 at 1:36 PM, Jan Hubicka wrote:
> >> @@ -730,6 +726,8 @@ void cgraph_clone_inlined_nodes (struct
> >> void compute_inline_parameters (struct cgraph_node *);
> >> cgraph_inline_failed_t cgraph_edge_inlinable_p (struct cgraph_edge *);
> >>
> >> +void cgraph_init_node_map (voi
On Thu, Apr 21, 2011 at 1:36 PM, Jan Hubicka wrote:
>> @@ -730,6 +726,8 @@ void cgraph_clone_inlined_nodes (struct
>> void compute_inline_parameters (struct cgraph_node *);
>> cgraph_inline_failed_t cgraph_edge_inlinable_p (struct cgraph_edge *);
>>
>> +void cgraph_init_node_map (void);
>> +void
> @@ -730,6 +726,8 @@ void cgraph_clone_inlined_nodes (struct
> void compute_inline_parameters (struct cgraph_node *);
> cgraph_inline_failed_t cgraph_edge_inlinable_p (struct cgraph_edge *);
>
> +void cgraph_init_node_map (void);
> +void cgraph_del_node_map (void);
Given that you don't even
Please review the latest patch. SPEC2k FDO testing pass.
Thanks,
David
On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li wrote:
> Here is the revised patch. Basic FDO testing went fine. I still saw
> the ipa-inline assertion in SPEC FDO. Will run it when the regression
> is fixed.
>
> Thanks,
Discard this version of the patch. I have not updated source properly
and the build/test was invalid.
David
On Wed, Apr 20, 2011 at 11:22 AM, Xinliang David Li wrote:
> Here is the revised patch. Basic FDO testing went fine. I still saw
> the ipa-inline assertion in SPEC FDO. Will run it when th
Here is the revised patch. Basic FDO testing went fine. I still saw
the ipa-inline assertion in SPEC FDO. Will run it when the regression
is fixed.
Thanks,
David
On Tue, Apr 19, 2011 at 5:33 PM, Jan Hubicka wrote:
>> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
>> >> Actually, among all
> On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
> >> Actually, among all the choices, funcdef_no is probably the most dense
> >> one -- it is for function decl with definition only. In LIPO, the
> >
> > Yes, funddef_no is densiest, but we don't really need great density here
> > (in many ot
On Tue, Apr 19, 2011 at 4:49 PM, Jan Hubicka wrote:
>> Actually, among all the choices, funcdef_no is probably the most dense
>> one -- it is for function decl with definition only. In LIPO, the
>
> Yes, funddef_no is densiest, but we don't really need great density here
> (in many other places w
> Actually, among all the choices, funcdef_no is probably the most dense
> one -- it is for function decl with definition only. In LIPO, the
Yes, funddef_no is densiest, but we don't really need great density here
(in many other places we index arrays by cgraph_uid - it is intended for
that purpo
On Tue, Apr 19, 2011 at 4:30 PM, Jan Hubicka wrote:
>> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> >> So between hashtab and VEC, which one do you prefer? Either one is fine
>> >> with me.
>> >
>> > I would go with VEC. While the array will have holes, there are not many
>> > since
> On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
> >> So between hashtab and VEC, which one do you prefer? Either one is fine
> >> with me.
> >
> > I would go with VEC. While the array will have holes, there are not many
> > since
> > the ids are originally assigned sequentially.
> >
> > A
On Tue, Apr 19, 2011 at 3:57 PM, Jan Hubicka wrote:
>> So between hashtab and VEC, which one do you prefer? Either one is fine with
>> me.
>
> I would go with VEC. While the array will have holes, there are not many
> since
> the ids are originally assigned sequentially.
>
> Actually given that
> So between hashtab and VEC, which one do you prefer? Either one is fine with
> me.
I would go with VEC. While the array will have holes, there are not many since
the ids are originally assigned sequentially.
Actually given that we do IPA pass now, I think you can just remove cgraph->pid
field
So between hashtab and VEC, which one do you prefer? Either one is fine with me.
Thanks,
David
On Tue, Apr 19, 2011 at 3:39 PM, Jan Hubicka wrote:
>>
>> Why is VEC any better in terms of density ? Are you suggesting using a
>> hash table?
> It is not any better, but we usually use VEC for varia
>
> Why is VEC any better in terms of density ? Are you suggesting using a
> hash table?
It is not any better, but we usually use VEC for variably sized arrays like
this one. Not that I would be big fan of its API, but at least it fives
bounds checking that would catch bugs like one you are fixin
On Tue, Apr 19, 2011 at 2:38 PM, Jan Hubicka wrote:
>> Hi, Insane value profile data may contain indirect call targets with
>> wrong (corrupted) pids. r172276 solves the problem when the pid
>> refers to a bogus target that is still 'alive'. This patch addresses
>> the issue when the bogus target
> Hi, Insane value profile data may contain indirect call targets with
> wrong (corrupted) pids. r172276 solves the problem when the pid
> refers to a bogus target that is still 'alive'. This patch addresses
> the issue when the bogus target is already eliminated or pid is too
> large.
>
> OK aft
18 matches
Mail list logo
