Re: Emacs-diffs Digest, Vol 94, Issue 89

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>
>> Date: Fri, 24 Sep 2010 22:29:02 +0200
>> 
>> Eli Zaretskii <address@hidden> writes:
>> 
>> > Or maybe you mean that Stefan thought casting was not the best idea.
>> > In that case, I'd like Stefan's opinion on this one:
>> >
>> >> -  int frame_lines = FRAME_LINES (frame);
>> >> +  EMACS_INT frame_lines = FRAME_LINES (frame);
>> >
>> > I think down that lane lies madness, because we have lots of struct
>> > members that are Lisp integers, and assigning the result of XINT of
>> > every one of them to an EMACS_INT will significantly and unnecessarily
>> > increase our stack usage (on 64-bit machines).
>> 
>> "Significantly"?  Reality check.
>
> Yes, indeed.  Take a look at GC some day, it uses up tens of thousands
> of recursive calls as a matter of routine.

And how many of those garbage collection calls are involved in this
particular issue?  About zero I should guess.

> And even without GC, there are about 30 frames on the stack any time I
> debug Emacs.

Of which there are, pessimistically speaking, probably 10 affected.  So
we are talking about several dozens of wasted bytes at any given point
of time.  Very much dwarved by the stack requirements of garbage
collection, according to you.

> If we pacify -Wconversion by using EMACS_INT for every variable that
> sometimes gets assigned the result of XINT or XFASTINT, that could be
> quite a lot of memory waste.

We are talking about automatic variables here.  When optimizing, the
compiler does not even reserve stack space when it does not need it.  In
fact, you are likely getting code bloat if you force intermediate values
into variables of smaller size than the original type.  The compiler
works with 64-bit registers in the affected architectures, anyway, and
it needs to fiddle with masking/extending operations in order to
simulate 32-bit variables.  It generates extra code in order to produce
the behavior that the compiler warns about.

-- 
David Kastrup