On Fri, Feb 23, 2018 at 04:27:07PM +0100, Maxime Villard wrote: > Le 23/02/2018 à 15:37, Joerg Sonnenberger a écrit : > > On Fri, Feb 23, 2018 at 03:35:02PM +0100, Maxime Villard wrote: > > > Le 23/02/2018 à 15:07, Maxime Villard a écrit : > > > > > Then figure out why not. Placing random pessimisation options all over > > > > > the place is wrong. > > > > > > And also, could you expand a little bit about what is inherently wrong > > > with > > > putting -fno-shrink-wrap on CFLAGS and not DEFCOPTS? > > > > The only valid reason for wanting -fno-shrink-wrap is to work around the > > broken unwind logic in DDB. If you don't use or care about DDB, there is > > no reason to want it. This is the same as with -fno-omit-frame-pointer. > > It just increases code size and slows things down. > > Well... Yes. But we do have -fno-omit-frame-pointer, because we do care about > DDB. So why not put -fno-shrink-wrap along the way? This one does not increase > the code size, it just pushes the frame a little earlier. (I don't see how > this is specific to DEFCOPTS, by the way.)
-fno-omit-frame-pointer should *not* be part of Makefile* either, for the very same reason. It should be removed, except I wouldn't be surprised if modules depend on it or something else stupid. Shrink wrapping doesn't increase code size, but length of code chains for short cuts. I.e. if a function has a cheap case as initial condition that is often hit and doesn't require a stack frame, it won't get one either on that branch. Joerg
