Hi Alastair,
In addition to your planned tasks, you might want to put in some work to ensure
branch probabilities are not lost during optimization. One known issue is LLVM
optimizer can turn branchy code into switch statements and it would completely
discard probability. Here is a simple example:
static void func2(int N, const int *a, const int *b, int *c)
__attribute__((always_inline));
void func4(int N, const int *a, const int *b, int *c)
__attribute__((noinline));
void func8(int N, const int *a, const int *b, int *c) __attribute__((noinline));
void func2(int N, const int *a, const int *b, int *c) { *c = 2 + *a + *b; }
void func4(int N, const int *a, const int *b, int *c) { *c = 4 + *a + *b; }
void func8(int N, const int *a, const int *b, int *c) { *c = 8 + *a + *b; }
extern void func(int N, const int *a, const int *b, int *c)
{
if ( __builtin_expect(N==2, 1) )
func2(N, a, b, c);
else if ( __builtin_expect(N==4, 0) )
func4(N, a, b,c);
else
func8(N, a, b,c );
}
Thanks,
Evan
On Jul 16, 2012, at 10:10 AM, Alastair Murray <alastairmurray42 at
gmail.com> wrote:
> Hi all,
>
> In light of the expected removal of ProfileInfo this is a request for
> comments on the next few items that I now plan to work on for GSoC.
>
> Planned tasks:
>
> #0 Add support for determining branch weight metadata by profiling
>
> At the absolute minimum this will require writing a new profile loader
> which will set branch weight metadata based on profiling data.
>
>
> #1 Optionally use profiling support to heuristics within:
> * Loop unrolling
> * Loop unswitching
> * Inliner
>
> The existing BranchProbabilityInfo, and BlockFrequencyInfo are not used
> in Transforms/*/* at all, just in CodeGen/*. Is there a reason for
> this, or is it quite possible to use them in Transforms/*/* passes? The
> original plan was to test these using ProfileEstimator, now the static
> heuristics within BranchProbability could be used instead until branch
> weight metadata is successfully maintained through CFG altering passes.
>
>
> #2 Make the profiler more JIT friendly
>
> The ProfileInfo based profiling support is not very friendly towards PGO
> within a JIT context. The main issue is that profiling data must go via
> the filing system. This will be addressed by providing a new
> libprofile_rt.so runtime library for JITs to use. This is planned to be
> demonstrated and documented by adding an extra chapter to the
> Kaleidoscope tutorial. (There is also an issue of profiling a single
> function rather than a whole program.)
>
> (For the record, there are also future plans to work on #3 profiling the
> targets of indirect function calls (highly likely) and #4 path profiling
> (not nearly as likely), but as it is not yet clear when these will be
> worked on I'll seek comment on these at a future date.)
>
> Regards,
> Alastair.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev