This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Move predictions list out of basic block


> Hello,
> 
> > I wonder why we don't have a tree_bb_info struct like we have
> > rtl_bb_info - the phi_nodes pointer would fit there as well as
> > the stmt_list? 

Well, it was the original plan but I never got around to implement the
second half. As Zdenek mentions it won't save that much because we
have all functions in gimple.
However my original plan to make them overlapping unions.  If the rtl
info is smaller than gimple info, we might save some indirection.
> 
> here is the patch that implements the idea, bootstrapped & regtested on
> i686.  Memory-wise, it probably won't save much (as function bodies are
> stored in gimple), though.
> 
> It would be possible to really save the two pointers by letting
> il.tree point to the list of stmts in block, and having phi nodes
> stored in TREE_CHAIN field of the list of statements.  It is a bit
> hacky idea, though.
> 
> > Also can we get at the loop_depth via loop_father?
> 
> Not necessarily, loops are not present all the time.  However,
> loop_depth field is almost unused, so it should be possible to move it
> away from bb.

Note that cgraph is still maintaining loop_depth but since we now have
profile I don't use it, so it can go away.
I wonder what other cases we have loop_depth used witout loop structure
built.
> 
> > Also gcov count and frequency look like duplicated information.
> 
> Execept for possible slowdowns, I think it would be possible to
> keep just counts (and remember the maximum count of a block in a
> function in cfun).  But I am sure Honza considered this and from
> some reason (maybe the slowdowns?) it is not possible?

The reason is that they are not really duplicates - ie it is possible
for counts to drop to zero, but frequencies still have useful
information ie when the code diplication was done.  It happens only in
cold sections of program, so it is probably not big deal, but that was
original idea (and also the fact that all the optimizers will not be
required to berform 64bit divides to get someting that can be safely
operated on)

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]