|Profile-driven optimization firstname.lastname@example.org (Tim Frink) (2008-01-29)|
|Re: Profile-driven optimization email@example.com (Gene) (2008-01-31)|
|Re: Profile-driven optimization firstname.lastname@example.org (=?ISO-8859-1?Q?Pertti_Kellom=E4ki?=) (2008-02-01)|
|Re: Profile-driven optimization email@example.com (M Wolfe) (2008-02-02)|
|Re: Profile-driven optimization firstname.lastname@example.org (Pasi Ojala) (2008-02-08)|
|Date:||Thu, 31 Jan 2008 17:18:59 -0800 (PST)|
|Posted-Date:||01 Feb 2008 20:44:12 EST|
On Jan 29, 5:29 am, Tim Frink <plfr...@yahoo.de> wrote:
> Recent versions of compilers perform profile-driven optimizations,
> i.e. they first profile the program by running it and collect
> information about the frequency of taken branches and how often basic
> blocks have been executed. Based on that, they get one path through
> the program that is executed most frequently.
> I'm now wondering what sort of optimizations can be performed to that
> path. ...
> [I wouldn't say it's recent. Multiflow's compiler was using profile
> feedback at least 20 years ago. There must be lots of papers since
> then. -John]
Straight-line code has no cache flushes, so instruction scheduling can
be more effective. You don't need a special algorithm, though. It
You might also repeat blocks to make more than one path straight-line.
If you have A(B|C)D and both paths profile as critical, then you might
compile A(BD|CD) to eliminate a jump at the end of B.
You might also tune the register allocator to specially favor
variables of the critical path for global register allocation with
minimal swaps and spills.
Indiscriminate inlining bloats code, which kills cache performance.
Inlining focused on the critical path makes sense.
Return to the
Search the comp.compilers archives again.