Messages in this thread | | | Date | Wed, 22 Apr 2009 01:47:52 -0400 | From | Mathieu Desnoyers <> | Subject | Re: [PATCH 2/8] tracing: create automated trace defines |
| |
* Steven Rostedt (rostedt@goodmis.org) wrote: > > [ removed Pekka@firstfloor.org due to mail errors ] > > On Tue, 21 Apr 2009, Frank Ch. Eigler wrote: > > > Hi - > > > > On Tue, Apr 21, 2009 at 05:17:17PM -0400, Steven Rostedt wrote: > > > > > [...] Perhaps we should fork off gcc and ship Linux with its own > > > compiler. This way we can optimize it for the kernel and not worry > > > about any userland optimizations. > > > > In this regard, kernel land does not seem that unlike user land. > > > > > if (unlikely(err)) { > > > __section__(".error_sect") { > > > /* put error code here */ > > > } > > > } > > > > > > And have gcc in the error section (if it is big enough perhaps) do: > > > jmp .L123 > > > .L124 [...] > > > [...] > > > jmp .L124 > > > > > We could do the same for trace points. That is, any part of code that > > > really would happen once in a while (error handling for one) we can move > > > off to its own section and keep hot paths hot. > > > > This is called -freorder-blocks or -freorder-blocks-and-partition > > (depending on how far you would like gcc to move unlikely blocks). > > That does not let us pick and choose what and where to put the code. > > But still, a fork of gcc would let us optimize it for the kernel, and not > for generic programs. > > /me has been sitting too close to the furnace and must have been taking > up some of those fumes, to be considering a fork of gcc a good idea ;-) >
I guess we should have been sitting near the same furnace then. I'm unsure how different from the current gcc this can go, but it could be a very interesting exercise. Just removing unneeded front ends could probably help adding features much faster than if we have to support Fortran, Java, etc.
Mathieu
> -- Steve >
-- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
| |