[llvm-commits] ideas for 10096

[Cameron Zwarich]

On Jun 28, 2011, at 11:35 AM, Rafael Ávila de Espíndola wrote:

> I am trying to fix 10203 and currently I have three ideas of how it 
> might be fixed:
> 
> *) Fix bit rot on the strong phi elimination. IT currently crashes when 
> building firefox.

If you can attach a reduced .ll file to a bug I should be able to look at it this weekend. When I stopped working on strong phi elimination it was working well on x86.

I don't think we will ever turn strong phi elimination on by default, at least in its current form. It doesn't give enough of an improvement in either compile time or the quality of generated code to be worth it. There are also tricky phase ordering issues between the 2-addr pass, strong phi elimination, and the coalescer.

> *) A simple preprocessioning pass that would try to convert
> 
>     %vreg40<def> = COPY %vreg45
>     %vreg42<def> = COPY %vreg45
> 
> to
> 
>     %vreg40<def> = COPY %vreg45
>     %vreg42<def> = COPY %vreg40
> 
> That is, try to use in the RHS values that have been defined in the same bb.
> 
> * The third idea (which I like a bit more right now) is to change the 
> coalescer itself
> 
>  Right now it works in three stages if I understand it correctly.
>  1) it collects which value numbers of A are copies of B and B of A.
>  2) It then optimistically merges the intervals, by first copying the 
> LHS and then the RHS with exceptions for the A=B and B=A cases.
>  3) It now walks the ranges of both registers looking for overlapping 
> ones. If it finds one, it checks if both have the same value number in 
> the new merged interval.
> 
>  I think this can be done in one pass. As we walk the ranges, we can 
> find the value numbers and check if they are compatible. Doing this in 
> one pass then has the advantage that it is easy to add support for the 
> case we have in the bug.
> 
> In this case, the dominance check can be as simple an "defined earlier 
> in the same bb".
> 
> So, do you agree with the third option being the best or would a 
> preprocess pass (or fixing the strong phi elimination) be better?

This one-pass algorithm sounds like a dominance-based coalescing algorithm applied to the live ranges of the two live intervals, with a dominance test approximated by something weaker. I would be worried about a compile-time regression, since I see the optimistic case kicking in quite a bit when running -debug on the coalescer. Can't you just handle this in the exceptional case of coalescing, i.e. check whether both valnos are defined by a copy of the same value in the same basic block and pick the first one to be the 'leader'?

I think the correct thing long-term is for phi elimination to produce parallel copies, and for the coalescer to take advantage of this. It would then be even easier to do this sort of a check. When checking whether two seemingly overlapping live ranges actually interfere, you could just check whether they are defined by the same value at the same parallel copy.

I have been working on this off and on with a branch, but I wanted to wait until linear scan is gone (taking physical register coalescing with it) before heavily modifying the coalescer on trunk.

Cameron