This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Merging calls to `abort'


----Original Message----
>From: Richard Stallman
>Sent: 15 March 2005 18:39

> Nonetheless, GCC may as well still stop cross-jumping abort calls.
> There's nothing to lose

  There *is* something to lose: memory space.  Lots of people use gcc to
develop for deeply embedded systems, where memory restrictions are hugely
onerous.  I think you are skating over this issue far too lightly.  The only
reference I could see to the memory costs associated with disabling this
optimisation was way upthread, where you wrote

"It saves a certain amount of
space; it has no other benefit.  All else being equal, there's no
reason not to do it.  But cross-jumping abort calls interferes with
debugging.  That's a good reason not to do it."

  Permit me to point out: that it is _precisely_ in the situations where
memory *is* critical, that there is no question of having room for debugging
overhead.

  What you casually dismiss as "no other benefit" can mean the difference
between "working" and "completely broken".  If you're coding for an embedded
cpu, and you've already rolled a hundred thousand units off the production
line, and all of a sudden the firmware won't fit, you've got a disaster on
your hands, and squishing a few jumps together can save your life.  You're
talking about systems where "adding more memory" is not a matter of plugging
in a few DIMMs, but of going back to your chip fab and spending another
couple of million dollars to re-tape-out your design with another 1k of rom
or whatever....

  So whatever harm may be done to the quality of debug info is not a
relevant consideration to the question of whether or not we should thread
jumps in a context where we are critically short of memory; including debug
info isn't an option anyway.

  I very strongly feel that this optimisation should be placed under user
control rather than just disabled, and that it should remain enabled by
default at -Os; but I wouldn't go to the ropes over whether or not it's
included in -Os as long as there's a -f that will allow me to switch it back
on.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]