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.