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]

Re: Value Range Propagation Patch -- Part 2 of 2



  In message <200005092119.RAA23408@jwlab.FEITH.COM>you write:
  > > I haven't thought about value-range propagation in any significant way, b
  > ut
  > > I think you can get the code you desire by starting with the most optimis
  > tic
  > > solution and iterate until you reach a steady state.
  > 
  > The current approach of ordering the basic blocks also seems to produce
  > the desired code though the routine which does the ordering can probably
  > be improved.
I'd make a distinction between correct and desired.  Regardless of the
order of the basic blocks we should still get correct code.  Whether or
not we get the desired code depends on a few factors like whether or
not we do the optimistic initialization vs pessimistic initialization.

  > I appreciate the suggestions.  I am curious if you have a specific object
  > to the current approach, or if you consider it unacceptable.  I imagine
  > the following concerns:
My "objection" to bb ordering is that it shouldn't be necessary for
correctness, only for possibly improving the compile time or compile speed
and that I'd prefer to use more standard ways of dealing with issues than
inventing new ones, the standard way to deal with the minimal vs maximal
solution is tweaking the initial state or moving to a stronger algorithm
for identifying and removing unreachable code like conditional constant
propagation.


  >   Correctness
  > 
  >     Does it generate correct code?
If the code is not correct regardless of the ordering of blocks, then the
implementation is wrong.


  >   Scaling
  > 
  >     Does it handle large, complex CFGs in a reasonable fashion?
It's not so much a question of complex CFGs, but what I call inverted
CFSs -- ie those with large numbers of nested backedges.  Basically

  > What do you see as things which need to happen in order for this to be
  > a useful addition to GCC?
I already think it is.  Sorry if I wasn't explicit about that.  I'm just
trying to work through why you did certain things and suggest alternatives
if certain implementation decisions aren't what I expected given what I've
read and know about some of this stuff.

jeff


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