[google] support for building Linux kernel with FDO (issue4523061)

[Rong Xu]

Thanks for the comments. This particular patch is not intended for
trunk. But we do want to hear your feedback on our designs.

On Fri, May 13, 2011 at 9:31 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Fri, May 13, 2011 at 5:54 AM, Paolo Bonzini <bonzini@gnu.org> wrote:
>> On 05/13/2011 03:03 AM, Rong Xu wrote:
>>>
>>>        * gcc/coverage.c        (revision 173717): set a flag if building
>>> for Linux kernel.
>>>        * gcc/tree-profile.c    (revision 173717): don't emit TLS
>>> declarations for Linux kernel builds.
>>
>> I think this should be done without touching at all the profiling machinery
>> in GCC.
>>
>> 1) add a new TLS model -ftls-model=none and make the kernel uses it. The
>> model would simply force targetm.have_tls to false.
>>
>
> This is a good idea.
>

Agreed. We can use the option together with -fprofile-generate.

>
>> 2) as Richi mentioned, gcov-io and libgcov changes then can move to the
>> kernel, and GCC needs no change at all here.
>>
>
> In fact -- reuse gcc code profiling machinery for FDO is the KEY
> objective in this effort --- the effort tries to minimize gcc changes
> by refactoring gcc code and isolating/abstracting away part of gcc
> implementation that is user space program specific without using
> runtime hooks.  Aside from the kernel FDO change -- the refactoring
> itself actually makes the libgcov code more readable -- the existing
> implementation has many huge functions etc.
>
> Kernel source has their implementation of coverage testing -- but it
> makes lots of data structure assumptions and hard coded -- it can
> easily out of sync with gcc and is considered  unmaintainable.
>
> Rong will have more explanation on the design.
>

David has said most I want to say. I just add one more thing: kernel
can be compiled with many versions of gcc where libgcov is not
guaranteed to be compatible. It's will be messy if we put the all
versions of libgcov code into kernel. It's much cleaner to reuse the
libgcov code in gcc. For maintenance, it's better to have a central
place for one functionality.

The functionality in libgcov can be rough divided into the following part:
(1) gcov_init support: kernel need to have it's own version.
(2) runtime profile support: this part is mostly neutral to user-space
mode or kernel mode. Only some LIPO support needs to use a few libc
functions.
(3) dumping the profile file (traverse gcov_list, compute summary,
merging profile, wrtie gcda file etc). I would say most of the
functionalities are neutral. Only the file I/O  part is specific to
user-mode. Kernel's merging function is not necessary as it can be
done offline. We need to refactor gcov_exit() so it can dump one
individual gcov_info.

So I think it's reasonable to factor the libgcov code to provide
kernel support.  There are many place in this patch can be improved in
this regard, but here are the key points of our design that we want to
keep:
(1) The functionality of dumping gcov_info (independent of use-space
mode or kernel mode) should be in gcc.
(2) libgcov source in gcc will be exported to kernel.

We can re-factor current implementation to separate kernel code. I
have another patch that puts all the kernel code into separated files
(and they can easily be moved to kernel.)


> Thanks,
>
> David
>
>
>> BTW, these parts of LIPO:
>>
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_gcov_type_ptr_var) =
>>> +         decl_default_tls_model (dc_gcov_type_ptr_var);
>>>
>>>       dc_void_ptr_var =
>>>        build_decl (UNKNOWN_LOCATION, VAR_DECL,
>>> @@ -1488,8 +1493,9 @@
>>>                    ptr_void);
>>>       DECL_ARTIFICIAL (dc_void_ptr_var) = 1;
>>>       DECL_EXTERNAL (dc_void_ptr_var) = 1;
>>> -      DECL_TLS_MODEL (dc_void_ptr_var) =
>>> -       decl_default_tls_model (dc_void_ptr_var);
>>> +      if (!is_kernel_build)
>>> +        DECL_TLS_MODEL (dc_void_ptr_var) =
>>> +         decl_default_tls_model (dc_void_ptr_var);
>>
>> Probably are missing a !targetm.have_tls.
>>
>> Paolo
>>
>