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: [tree-ssa, RFC] CFG transparent RTL expansion


On Thu, 2003-12-18 at 19:44, Jan Hubicka wrote:
> Hi,
> I am attaching patch implementing the quite much discussed idea of expanding
> RTL out of GIMPLE CFG transparently.  The patch do have some rough edges and
> can be decomposed to about 5 incremental steps so it is not intended for
> detailed review rather than a demonstration/proof of the concept in a hope that
> it will make decision easier (the patch however bootstraps and works well).
> 
> The problem I am trying to solve is question on how to preserve profile
> information out of SSA based passes.  It is clear that most effective consumers
> of profile include inlining, loop optimization, register allocation and basic
> block reordering so profile must be available in about whole compilation pass.
> Actually measuring profile in multiple stages of compilation is possible, but
> earlier optimizations invalidate later measured profile so it require user to
> do multiple train runs that is unfortunate so I think it is a must to have
> machinery to preserve profile as well as possible from before inlining up to
> final.
> 
> From the work on RTL, the experience shows that CFG is the most natural place
> to store information into and about only place where updating after control
> flow transformations is manageable (still not easy), the alternatives like
> remembering execution counts for each instructions or branch probabilities for
> conditional branches does not work well for nontrivial updates.

I need more details :-). 

This implements something which isnt actually used yet (ie, no
collection emitted/done). If I read it correctly, just a proof of
concept of a persistant CFG. So lets skip to how it would actually be
used. And excuse my lackof knowledge about how gcc collects profile info
:-)

1 - Where do you propose to emit the measurement code, and where do you
plan to read it in? Presumably they have to be the same location...  I
assume the measurement code is currently emitted in RTL land, probably
early in the rtl cycle? Would we be doing that in the front end, or in
SSA land? or just before SSA after the CFG is created?

2 - Does profiling work on abnormal edges?  Ie, are throw edges
annotated, or are they guessed/ignored/calculated when possible?

3-  So, assume the profile information on trees is going to be kept in
the CFG only right through into RTL. When I inline function 'a' into
function b:

  int a(int y)
  {
    if (y < 20)   
      return 1; 
    else
      return 0;  /* Profiling says this branch is taken 90% of the time.  */
  }

  void b()
  {
    <...>
    a(z)
    <...>
  }


simplistic example, but lets say profiling indicates that we ought to
inline a(z) when we are processing b. How does that profile information
from a() get propagated into the code which is inlined into b? There is
no CFG for a(), just the trees. Do you have to read the info for a() in
from the profile source each time its inlined or how does that work?

4- Does anyone other than me find the idea of inlining optimized trees
appealing? I understand thats not on the table right now because there
are difficulties with EH, at the very least. I would think we could
encapsulate that info somehow, but clearly thats a problem that would
need to be solved.

Im sure more questions will occur to me, but thats it for now :-)

Andrew


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