llvm dev - Jan 2013 - [LLVMdev] Order of optimization: modulo scheduling & register allocation

I was reading about the order of optimizations in the code generation stage
here:
http://llvm.org/docs/CodeGenerator.html#the-high-level-design-of-the-code-generator

This is the part that's interesting to me:

3. SSA-based Machine Code
Optimizations<http://llvm.org/docs/CodeGenerator.html#ssa-based-machine-code-optimizations>—
This optional stage consists of a series of machine-code optimizations
that operate on the SSA-form produced by the instruction selector.
Optimizations like* modulo-scheduling* or peephole optimization work here.
4. Register
Allocation<http://llvm.org/docs/CodeGenerator.html#register-allocation>—
The target code is transformed from an infinite virtual register file
in
SSA form to the concrete register file used by the target. This
phase*introduces spill code
* and eliminates all virtual register references from the program.

If modulo scheduling happens before more code is introduced, how do we know
that we still have an optimal schedule?  Is there another scheduling stage
during later optimization?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130123/441fd3f2/attachment.html>

On Jan 23, 2013, at 3:45 PM, ryan baird <ryanrbaird at gmail.com> wrote:
> I was reading about the order of optimizations in the code generation stage
here:
http://llvm.org/docs/CodeGenerator.html#the-high-level-design-of-the-code-generator
> 
> This is the part that's interesting to me:
> 
> 3. SSA-based Machine Code Optimizations — This optional stage consists of a
series of machine-code optimizations that operate on the SSA-form produced by
the instruction selector. Optimizations like modulo-scheduling or peephole
optimization work here.
> 4. Register Allocation — The target code is transformed from an infinite
virtual register file in SSA form to the concrete register file used by the
target. This phase introduces spill code and eliminates all virtual register
references from the program.
> 
> If modulo scheduling happens before more code is introduced, how do we know
that we still have an optimal schedule?  Is there another scheduling stage
during later optimization?
There is a post-RA scheduling pass. It is only used when compiling for in-order
CPUs. Out-of-order CPUs usually don't care.

/jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130123/05eb1ff9/attachment.html>

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes:
>     If modulo scheduling happens before more code is introduced, how
>     do we know that we still have an optimal schedule?  Is there
>     another scheduling stage during later optimization?
I think in general that a modulo scheduler will have to mark a
scheduled block to be untouched by other things.  There are too
many strange things that can happen in-between the scheduler
and actual asm emission.
> There is a post-RA scheduling pass. It is only used when compiling for
> in-order CPUs. Out-of-order CPUs usually don't care.
There are any number of reasons to do scheuling for out-of-order
machines.

                           -David