2015-07-06 10:20, Bruce Richardson:
> On Fri, Jul 03, 2015 at 09:57:26PM +0200, Thomas Monjalon wrote:
> > 2015-07-03 16:56, Bruce Richardson:
> > > On Fri, Jul 03, 2015 at 05:45:34PM +0200, Thomas Monjalon wrote:
> > > > Hi Bruce,
> > > > 
> > > > 2015-07-03 16:40, Bruce Richardson:
> > > > > As well as the fast-path functions in the rxtx code, there are also
> > > > > functions which set up and tear down the descriptor rings. Since these
> > > > > are not performance critical functions, there is no need to have them
> > > > > extensively optimized, so we add __attribute__((cold)) to their
> > > > > definitions. This has the side-effect of making debugging them easier 
> > > > > as
> > > > > the compiler does not optimize them as heavily, so more variables are
> > > > > accessible by default in gdb.
> > > > 
> > > > What is the benefit, compared to -O0?
> > > 
> > > First off, it's per function, rather than having to use -O0 globally. 
> > > Secondly,
> > > it doesn't disable optimization, it just tells the compiler that the code 
> > > is
> > > not on the hotpath - whether or not the compiler optimizes it is up to 
> > > the 
> > > compiler itself. From GCC documentation: 
> > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
> > > 
> > > "The cold attribute on functions is used to inform the compiler that the 
> > > function is unlikely to be executed. The function is optimized for size 
> > > rather 
> > > than speed and on many targets it is placed into a special subsection of 
> > > the 
> > > text section so all cold functions appear close together, improving code 
> > > locality of non-cold parts of program. The paths leading to calls of cold
> > > functions within code are marked as unlikely by the branch prediction 
> > > mechanism.
> > > It is thus useful to mark functions used to handle unlikely conditions, 
> > > such as
> > > perror, as cold to improve optimization of hot functions that do call 
> > > marked
> > > functions in rare occasions."
> > 
> > I know it may provide some optimization of the hot path.
> > I was asking compared to -O0 because you were justifying this change for 
> > debug.
> > In other words, for debugging, -O0 is probably better. So the reason of this
> > change should be the optimization. And it would be interesting to know if 
> > you
> > have seen some performance improvement.
> 
> For some cases, O0 will be necessary, but the advantage of this change is that
> for debugging of code that is not in the fast-path, the use of -O0 may be 
> unnecessary - which is useful, since you don't always need to do a special 
> debug
> build.
> 
> As for performance impact: no, I have not seen any performance impact from 
> this
> change. Personally, I view this as a low impact change that doesn't really 
> have
> any negatives. Is there some concern in particular you have about it? It's 
> really
> just providing some extra hints to the compiler.

No concern. I was only interested to fully understand why you made this change.
Thanks

Reply via email to