This is the mail archive of the 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: Moving some VRP bits from DOM into tree-vrp

On Tue, Jun 14, 2005 at 03:38:29PM -0600, Jeffrey A Law wrote:
> On Mon, 2005-06-13 at 19:47 -0400, Diego Novillo wrote:
> > On Mon, Jun 13, 2005 at 05:24:10PM -0600, Jeffrey A Law wrote:
> > 
> > > For better or worse, I've found that DOM is still finding a lot of
> > > stuff that is being missed by other passes.  So this process isn't
> > > simply "remove large hunk of DOM code, but instead is going to involve
> > > improving the other passes so that they're catching most (if not all)
> > > of the things DOM does.
> > > 
> > Yes, I did some experiments a few days ago.  I switched off all
> > the transformations done by DOM using the VRP records.  It
> > resulted in almost negligible losses in the amount of jumps
> > threaded:
> > 
> > cc1-i-files:	-0.21%
> > DLV:		-0.09%
> > MICO:		-0.05%
> > SPEC2000:	-0.96%
> > TRAMP3D:	-0.05%
> > 
> > Most of the opportunities came from dummy statements created by
> > DOM.
> But as with so many things, just counting the jumps threaded 
> is _not_ the right way to evaluate the utility of code in DOM
> (as I've stated many many times).
I never said I was evaluating the general utility of code in DOM.
I was merely counting jumps threaded.

>  > Why not do this in substitute_and_fold?  It knows about the
>  > ranges and does a full IL scan already.
> It appears to only deal with ranges that have collapsed down to
> a single value.
No.  Look again.  You want to extend fold_predicate_in into a
more generic range-based folder.

> I'm not absolutely sure we want to pollute that code with
> general simplifications based on range information.
On the contrary.  That's exactly the place where these
simplifications go.  At this point we have finished propagating
all the ranges and are traversing the whole IL looking for ways
of using the known ranges.  Otherwise, you are just adding a
second IL traversal for no reason.

If you want, what we can do is change the boolean argument
'use_ranges_p' into a callback function.  Note that
fold_predicate_in calls back into tree-vrp.c to get range
information.  We can encapsulate that even more and make the
whole thing a call back, but the net effect is the same.

> For the transformations I just added we don't need the range to
> collapse to a single value.  In the DIV/MOD case we just need to
> know the range is non-negative and in the ABS case we just need
> to know that the range can not include both positive and negative
> values.
> And the next transformation that needs to move from DOM to VRP we'll
> be using range information to simplify (but not eliminate) conditionals.
> For example, if we have a range [-INF .. 25 ] and we have a conditional 
> x >= 25, then we can turn the conditional into x == 25.
My suggestion is to rename 'fold_predicate_in' into
'simplify_using_ranges', which would receive the single statement
and do either of these two transformations you mention above, or
the standard predicate folding of COND_EXPRs.


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