flow rewrite

Jeffrey A Law law@cygnus.com
Thu Jan 21 01:48:00 GMT 1999


  In message < 19990117200057.A18075@dot.cygnus.com >you write:
  > I've completed that flow rewrite I started back in October.  As a
  > reminder, this was intended to create real basic block structures
  > and a proper edge list.
  > 
  > It bootstraps with no regressions on Alpha, i686, and Sparc.
First, I'd suggest a little more detail about what you're trying to do and
why.  I suspect I've got a reasonable clue, but it'd be nice if you could
say something about the overall design and benefits so that other folks would
have a chance of understanding without reading 100k of diffs :-)

The high level stuff would even help me.  It's easy to get lost in that
big of a patch.

  > There is one bit of nastiness coming from wanting to run flow2 after
  > the prologue and epilogue insns have been added.  Can someone tell
  > me why call_used_regs must include fixed_regs?  This loses information
  > what is otherwise useful.  Especially since the existing definition
  > could be obtained by (used || fixed).
It's been that way as long as I can remember.  There's no documentation about
why.  Just that comment you see in front of CALL_USED_REGS for most ports:

/* 1 for registers not available across function calls.
   These must include the FIXED_REGISTERS and also any
   registers that can be used without being saved.
   The latter must include the registers where values are returned
   and the register where structure-value addresses are passed.
   Aside from that, you can include as many other registers as you like.  */


Why do you include tree.h & expr.h in flow.c?  Similarly for the scheduler.
Those are all files that typically associated with front end or the tree->rtl
conversion phase, not the rtl optimizers.


Mostly it looks good.  I'd like to take another look at the block merging code
(having already written one I can offer some ideas :-)

What I didn't see was the code which maintains block #s through the life of
a compilation unit.  Or are we not doing that yet?

What (if any) thoughts do you have on being able to reorder blocks?  The
case I'm thinking about is removal of blocks which are physically inside a
loop, but not really part of the loop (ie, the blocks which are not reachable
by following preds from the block(s) with the loop back edge.)

I guess in a more general sense, given a cfg, I would like to be able to made
arbitrary changes to the cfg and have it handle creating new blocks, jumps,
fixing jump targets, etc etc.

I'm going to take another look at it tomorrow and probably bootstrap it
on a PA and maybe some other targets.




jeff



More information about the Gcc-patches mailing list