On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> 1 - Pass cleanup. There have been rumblings about this, but I haven't > seen a lot of actual progress. We currently run 100's of passes all the > time, and we don't really know how effective or necessary many of them > are. We also don't know whether the cleanups they run are truly doing > much. It would be nice to do some actual analysis and do something with > the results. Yes, this is an area that is in desperate need of TLC. Your plan looks good to me. We need to have a mechanism to determine whether a pass did something, we need to be able to have different pipelines for different architectures. Do you have anything specific in mind? Create a branch? Work directly on mainline? Perhaps the first stage would be to define the logging so we can start doing some analysis. > 2 - Interface to the virtual operands. The virtual operand web provides > what really amounts to low level detail of memory accesses. Every pass > that cares about memory access ends up interpreting the data and dealing > with the VOP web modification itself. This is in some ways analogous to > every pass having to implement bsi_insert() itself. It would be nice if > there was one standard central interpreter of the data that knows how to > view and modify the web. Richi is working on an alias oracle of some > sort, I'm not sure of its details so I don't know how far it delves into > this sort of thing, or what approach it takes. Yes, we have to stop relying on the accuracy of the memory ssa web to do memory optimizations. It should just be used to produce a conservative answer. Anything that we want to keep in too much detail only blows memory utilization and compile time. One additional thing I want to have in this area is the ability to completely turn off alias analysis. We have run into several pathological cases that take the compiler out for a long spin. Dan has fixed the ones we found in PTA, I'm on the hook to fix one in memory partitioning, but in general I would like to have a Big Switch we can use in extreme cases. This is useful when you are dealing with a soon-to-be-released compiler and don't want to muck around something like alias analysis. In fact, it would be useful to have a generic time-out mechanism for passes to use. This way, users could place a limit on the amount of optimization effort they want the compiler to spend. I think this would be better implemented as a polling mechanism and passes should be responsible for undoing their own actions. I'm not really sure how to go about it in general. I think the amount of automatic infrastructure we can provide here is limited because most of the interesting work will be pass-specific. > 3 - SRA. There appear to be some deficiencies in SRA, and also how it > interacts with the MEMSSA partitioner. I found when looking at some 4.3 > bugs that its never as simple as looking at the base and offset, at > least not consistently. Most of it appears to be > first-implementation-itis, the discovering of new issues as you go. > Stepping back and reviewing the functional requirements and its > interaction with the partitioner should be useful. Agreed. SRA needs a new implementation. > 4 - SSA pressure reduction. I'm throwing this back on the table. I never > quite got around to it before, and nothing has changed to resolve the > issues. We freely create as much register pressure in the SSA optimizers > as we want (as we should be able to). The backend has doing nothing to > address the issue and the RTL register allocator is simply swamped by > the sheer quantity of live ranges sometimes. Perhaps Vlad's RA will get > in this release, and/or perhaps the need for this will be eliminated by > something else, but it is something that may help code generation in the > short term at least. What about the RTL expansion from SSA directly? This is an area that is going to affect the tuples branch very soon. We are currently going into RTL from tuples directly (no TER), but since most passes have not been converted, I can yet tell how much of a problem this is. In a few weeks we'll hit this problem. > If anyone is interested in any of these tasks, or has any > questions/observations/criticisms, please let me know. (I know you will! > :-) Definitely interested in #1 and #2. Though #4 will probably affect me the most short-term. Diego.
