This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [google] support for building Linux kernel with FDO (issue4523061)
On Sun, May 15, 2011 at 3:27 AM, Jan Hubicka <hubicka@ucw.cz> 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.
>>
>>
>> > 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.
>
> Yep,
> I think it does make sense to share the implementation, but we need to find
> resonable way to do so. ?I guess we could separate out the i/o bits
> into interface generic enough to cover the needs, move libgcov into its
> own directory (just like libgcc is these days) and add an configury option
Honza, Thanks for the comments. Can you elaborate what the options
will be look like?
-Rong
> that sets the interface. ?The kernel's interface can then be implemented
> in a single file instead of tons of ifdefs and I guess can sit either in kernel
> or gcc tree...
>
> Honza
>>
>> Rong will have more explanation on the design.
>>
>> 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
>> >
>