Re: [tree-ssa]: PATCH: hookize profiling

[Jan Hubicka <jh at suse dot cz>]

> 
> They can, but I don't think it would gain anything, and this is the way 
> it was before.
> I moved ctr_labels down because they never need to be initialized at all
> when tree-based counters are used.

Hmm, when you do RTl profiling do you need the tree tables?
If so, it is fine to keep it here.
> 
> >Also perhaps it would be more safe to count number of counters in
> >advance instead of doing tricks with the array, but I guess this is OK
> >for first incarnation of patch.
> 
> That would be an extra pass, wouldn't it?  I don't think it's worth 
> that.

It is not terribly expensive to count them, but probably it is fine to
do it this way.
> 
> >>+
> >>+   if (!ir_type ())
> >>+     {
> >>        /* Re-merge split basic blocks and the mess introduced by
> >>  	 insert_insn_on_edge.  */
> >>        cleanup_cfg (profile_arc_flag ? CLEANUP_EXPENSIVE : 0);
> >>!       if (profile_dump_file())
> >>! 	dump_flow_info (profile_dump_file());
> >>!     }
> >Perhaps it can be cleaner if this was put out into rest_of_handle* 
> >where
> >we usually do the cleanups/dumping anyway.
> 
> This is where it was before, I just put it inside !ir_type().

Hmm, there is other call to dump_flow_info earlier, so lets keep it this
way.
The moving to rest_of_compilation would save one conditional and in the
case we will move to some kind of pass manager, we will need to do it
anyway.
> 
> >>+ /* Return 1 if BB ends with a call, possibly followed by some
> >>+    instructions that must stay with the call, 0 otherwise.  */
> >>+
> >>+ static bool
> >>+ tree_block_ends_with_call (basic_block bb)
> >>+ {
> >>+   block_stmt_iterator bsi = bsi_last (bb);
> >>+   tree t = tsi_stmt (bsi.tsi);
> >>+   if (TREE_CODE (t) == MODIFY_EXPR)
> >>+     t = TREE_OPERAND (t, 1);
> >>+   return TREE_CODE (t) == CALL_EXPR;
> >
> >GIMPLE grammar allows:
> >(return_expr (modify_expr (lvalue) (call_expr ...)))
> >so you need to skip return_expr here too.
> 
> I tried to get this to happen and couldn't.
> The call result always went through a temporary.
> But certainly allowing the case can't hurt anything, so I'll add it.

I know that the nested modify_exprs happens only for C++, but I am not
quite sure in what scenarios.  I checked some other passes and they all
seems to skip RETURN_EXPR here, so lets just be on safe side.

> 
> I'll work on making your other changes.
Thanks.
Honza