寄存器分配后的常量传播

Question

I am wondering why it is not advisable to do constant propagation after register allocation (RA) as well. After several optimization passes (post RA) there is scope for peephole optimizations like constant propagation/dead-code elimination etc. I can think of only two reasons,

1. that these optimizations are easy to do on SSA form.
2. peephole opt. post RA will result in increased compilation time.

Are there any other reasons?

If it is okay to perform peephole opt. post RA then what should be the data structures/algorithms (any paper, reference etc. would be helpful).

EDIT: in response to 500 - Internal Server Error's comment. After optimization passes like phi-elimination (which is, eg, in llvm-clang, merged with register allocation), global scheduling like: pulling up instructions to parent basic blocks etc.

EDIT2:

In the example shown in figure: The register allocator figures out that v1 and v2 has the same value and hence, assigns same register (r1) to them. After register allocation a common sub-expression elimination pass can eliminate r2 = r1 from basic block #4.

Answer 1

See: Constant folding

The example given,

 int x = 14;
 int y = 7 - x / 2;
 return y * (28 / x + 2);

The value x is completely unused after the constant folding. If RA was used first, it would create registers for x . So there is a chance for some pruning before running the RA phase, even if the results are the same. If there are even more variables, spills could be avoided. These would be difficult to undo after the registers are allocated.

I think that instead of constant propagation you are thinking of strength reduction ? This is more in the spirit of peephole optimizations ; or I don't understand what you mean by constant propagation during the peephole phase, which is usually a back-end portion.

Any Constant folding that was applied before register allocation should be identical, unless variables have been made constant or code was found dead; Ie the CFG has changed. ^{per Mystical}

SSA Elimination after Register Allocation describes the LLVM structure. I believe that the SSA could be annotated with constant values so that on Phi elimination unneeded moves can be avoided. This is probably an artifact of the SSA elimination after RA and other compilers won't be experiencing this issue. A separate pass will slow compilation, so addressing the issue in existing passes would be better. I think the following code illustrates the issue,

 int foo(int a, int b)
 {
    int c;
    if(a > 0)
        c = 7;
    else
        c = a * b + 10;
    return a + c;
 }

Upon phi elimination the code looks like,

 int foo(int a, int b)
 {
    int c;
    if(a > 0) {
        c = 7;
        return a + c;  /* Should reduce to "a+7" */
    } else {
        c = a * b + 10;
        return a + c;
    }
 }