Related articles |
---|
[6 earlier articles] |
Re: Pitfalls in interference graph ? rayiner@gmail.com (Rayiner Hashem) (2007-10-01) |
Re: Pitfalls in interference graph ? rayiner@gmail.com (Rayiner Hashem) (2007-10-01) |
Re: Pitfalls in interference graph ? jeremy.wright@microfocus.com (Jeremy Wright) (2007-10-02) |
Re: Pitfalls in interference graph ? shafitvm@gmail.com (shafi) (2007-10-15) |
Re: Pitfalls in interference graph ? torbenm@app-6.diku.dk (2007-10-17) |
Re: Pitfalls in interference graph ? SidTouati@inria.fr (ST) (2007-10-18) |
Re: Pitfalls in interference graph ? rayiner@gmail.com (Rayiner Hashem) (2007-10-21) |
Re: Pitfalls in interference graph ? Sid.Touati@uvsq.fr (Sid Touati) (2007-10-24) |
Re: Pitfalls in interference graph ? parthaspanda22@gmail.com (2007-10-24) |
From: | Rayiner Hashem <rayiner@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 21 Oct 2007 19:39:27 -0000 |
Organization: | Compilers Central |
References: | 07-09-10407-10-021 07-10-058 |
Keywords: | registers |
Posted-Date: | 21 Oct 2007 18:06:54 EDT |
> Colouring hurts ILP extraction for both superscalar VLIW and EPIC
> processors. Even if the ILP is not exposed at the architectural level,
> compilers schedule operations to help the processor to extract it at
> execution time.
I can see how it would hurt ILP extraction if you do register
allocation before scheduling, but if you do it after scheduling I
don't see the problem. Perhaps you could explain the issue in a bit
more detail?
> If register allocation with coloring methods are used, the ILP of the
> generated code would not be easily extracted by the processor at
> execution time. Dynamic renaming is limited in practice (since the
> window od instructions is limited).
Dynamic renaming is certainly limited, but surely the instruction
window on any reasonable OOO processor is big enough to allow renaming
to take care of almost all false dependencies.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.