On 2/13/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> There are certainly performance issues here. There are limits on
> how much I, and the others who have worked on this have been able to
> change before we do our merge. So far, only those passes that were
> directly hacked into flow, such as dce, and auto-inc-dec detection
> have been rewritten from the ground up to fully utilize the new
> framework. However, it had gotten to the point where the two
> frameworks really should not coexist. Both implementations expect
> to work in an environment where the information is maintained from
> pass to pass and doing with two systems was not workable. So the
> plan accepted by the steering committee accommodates the wholesale
> replacement of the dataflow analysis but even after the merge, there
> will still be many passes that will be changed.
Does it means that compiler will be even more slower?
No, it will mean the compiler will be faster. Sooner if you help. You
seem to believe that the DF infrastructure is fundamentally slower
than flow is. I believe that there are other reasons for the current
differences in compile time.
AFAICT the current compile time slowdowns on the dataflow branch are due to:
* bitmaps bitmaps bitmaps. We badly need a faster bitmap implementation.
* duplicate work on insns scanning:
1. DF scans all insns and makes available accurate information
2. Many (most) passes see it and think, "Hey, I can do that
myself!", and they
rescan all insns for no good reason.
The new passes, that use the new infrastructure, are among the fastest in
the RTL path right now. The slow passes are the passes doing their own
thing (CSE, GCSE, regmove, etc.).
* duplicate work between passes (minor):
- on the trunk, regmove can make auto increment insns
- on the df branch, the auto-inc-dec pass makes those
transformations redundant
* earlier availability of liveness information:
- On the trunk we compute liveness for the first time just before combine
- On the dataflow branch, we have liveness already after the first CSE pass
Updating it between CSE and combine over ~20 passes is probably costly
compared to doing nothing on the trunk. (I believe having cfglayout mode
early in the compiler will help reduce this cost thanks to no iterations in
cleanup_cfg)
Maybe I overestimate the cost of some of these items, and maybe I'm
missing a few items. But the message is the same: There is still
considerable potential for speeding up GCC using the new dataflow
infrastructure.
Gr.
Steven
