Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Profile-driven optimization plfriko@yahoo.de (Tim Frink) (2008-01-29) |
| Re: Profile-driven optimization gene.ressler@gmail.com (Gene) (2008-01-31) |
| Re: Profile-driven optimization pertti.kellomaki@tut.fi (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) (2008-02-01) |
| Re: Profile-driven optimization news1@oregonw.com (M Wolfe) (2008-02-02) |
| Re: Profile-driven optimization albert@mustatilhi.cs.tut.fi (Pasi Ojala) (2008-02-08) |
| From: | Pasi Ojala <albert@mustatilhi.cs.tut.fi> |
| Newsgroups: | comp.compilers |
| Date: | Fri, 8 Feb 2008 17:01:47 +0000 (UTC) |
| Organization: | Tampere University of Technology |
| References: | 08-01-078 08-02-011 |
| Keywords: | optimize |
| Posted-Date: | 10 Feb 2008 17:28:18 EST |
On 2008-02-01, Pertti Kellomdki <pertti.kellomaki@tut.fi> wrote:
> So the trick that e.g. the Multiflow compiler used is to guess based
> on the profiling information which basic blocks will usually be
> executed in sequence, and do instruction scheduling (ordering of
> instructions) on this larger region.
We have a DSP with a 3-stage pipeline, and the backend optimizer
/parallelizer /scheduler can use profiling information for just
that. For each conditional jump either the fall-through or jump target
is preferred when moving instructions across basic blocks.
It does help, if you have representative test data.
The main problem is that as code modules get larger, generating
suitable profiling information gets proportionally harder.
-Pasi
Return to the
comp.compilers page.
Search the
comp.compilers archives again.