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: Some 4.4 project musings

Diego Novillo wrote:
On Fri, Feb 1, 2008 at 3:55 PM, Andrew MacLeod <> wrote:

1 - Pass cleanup. There have been rumblings about this, but I haven't

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?

I think I'll create a branch since its not completely clear if the chosen information will be sufficient.. First convert all the passes to pass some info back in an organized way and then there will be some collecting/experimenting to do. I'll do the trees first, but make sure it can be applied to RTL as well.

 2 - Interface to the virtual operands. The virtual operand web provides
 what really amounts to low level detail of memory accesses. Every pass

Richi's work will probably change what the web looks like, so this seems like a good item for me to defer for a bit until we see where we end up.
 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

Agreed. SRA needs a new implementation.

Richi's work may completely remove need for touching SRA, so I'm going to punt on this for the time being as well.
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.

Thats a lot more work, and by itself may actually increase pressure in the average case :-) It will be interesting to see if anything has changed in the past few years regarding RTL that gets generated without TER. It would be nice if it wasn't needed, but I'm not aware of work which has changed enough to help select better RTL patterns. we'll see :-) It will be interesting to see what happens. As an easy experiment, have you tried a straight comparison with -fno-tree-ter on SPEC or anything like that? It may give you some idea of what to expect.

The pressure is likely to go up since TER usually moves defs closer to the use... I have no data whatsoever, but I would think that TER reduces the pressure slightly in the average case. The larger pathological cases are a little more unpredictable.


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