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: [tree-ssa] copy prop vs. debugging

On Thu, 2003-07-10 at 19:21, wrote:
> In message <1057760521.29596.29.camel@p4>, Andrew MacLeod writes:
>  >I can do that when I add the stack-space reduction pass to the
>  >SSA->normal coalescer. Ie, when I try to merge various non-conflicting
>  >temporaries of the same type into a single variable. You certainly want
>  >to prioritize it to merge any which have a copy first (so we can
>  >eliminate the copy), and it should be simple enough to choose a user var
>  >over a compiler temporary to represent the merged location in those
>  >cases.
> I looked at this pretty briefly.  But it seems to me that:
> What I was thinking about was:
>   1. Do all the coalescing we do now as-is.  Basically meaning that we
>   try to coalesce renamed variables back to their root.
>   2. For each pair of objects that appears in a copy or in a PHI node
>   try to coalesce them (since they're copies or potential copies).
>   3. Try to coalesce unrelated temporaries of the same time to reduce
>   the number of temporaries we use.
>  >Does that also mean I shouldn't merge temporaries with user variables if
>  >there is not a copy?
> Unsure.  I think you should definitely merge them if they have a real
> copy or a potential copy via a PHI node.  When I was playing with Jason's
> stuff (which uses a lot more temporaries) we end up with a lot of copies
> between user vars and temp vars.

My current plan, and in fact the next thing Im about to tackle I think,
is to do coalescing as we do today. ie, merge all the SSA_NAME variables
back to their root, or a new root if required.

Then do a memory coalescing as a seperate conflict graph pass on the
result of that, before we actually go and rewrite the IL with the new
vars. (It will of course be turn-offable for debugging.) 

During this pass we'll build the conflict graph for the remaining vars,
and attempt to coalesce anything which occurs in a copy. Note that all
the out-of-ssa copies have already been inserted now, so nothing is
hidden.. there are no potential copies left, they are all real ones.

So anything we coalesce will definately remove copies at this point.
Hopefully a lot of them :-)

Once we've coalesced everything we can that is in the copy-of list, then
any remaining non-interfering variables can be coalesced to reduce
memory usage on the stack.

Anytime 2 variables are being merged, the resulting variable will be a
user defined variable if one of the 2 is user defined.

If they are both user defined...  well, we can either merge or not... If
it removes a copy, Im game. If it doesnt remove a copy... well, perhaps
its better to leave it and maybe some other temporary will merge with
it. then we dont have 2 user variables occupying the same memory
location. Maybe it doesnt matter.

I dont want to try to do it all in one conflict graph, or we'll end up
with a very large dense graph, and we are actually trying to do 2
different things. I want to keep them seperate at this point. If we
combined them, then the conflict graph is going to have to track all the
interferences between all the SSA_NAMEs instead of just the ones that
share a root variable. Doing it with 2 seperate graphs will give us a
large sparse graph and a small dense graph rather than a large dense
graph. On big programs I think it would probably be a noticable

I may change my mind as I implement and measure it, but for the moment I
think this seems better.

So that boils down to approximately what you say above, so we seem to be
in agreement on this issue :-)  Wasn't that easy?? :-) 



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