GNU bug report logs -
#1334
23.0.60; bug of bytecomp arithmetic operations
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 1334 in the body.
You can then email your comments to 1334 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello,
Current byte compiler has potential problems in arithmetic operations.
Examples are all on Intel 32-bit. Result may occur in other
environments.
1. Operations are all compiled to binary operations. It may cause
overflows or truncations in floating point data operations.
Examples.
(upper result is by interpreter, lower is by code after compile)
(let ((a most-positive-fixnum) (b 1) (c 1.0)) (+ a b c))
--> 268435457.0
--> -268435455.0
(let ((a most-positive-fixnum) (b -2) (c 1.0)) (- a b c))
--> 268435456.0
--> -268435456.0
(let ((a most-positive-fixnum) (b 2) (c 1.0)) (* a b c))
--> 536870910.0
--> -2.0
(let ((a 3) (b 2) (c 1.0)) (/ a b c))
--> 1.5
--> 1.0
2. Most integer constants are moved to the end of expressions and
pre-calculated at compile time. Changing of order may cause different
result from original expressions.
(In other words, `byte-optimize-delay-constants-math' should not be called)
Examples.
(let ((a (+ 1 (expt 2 -52))) (b (expt 2 -53))) (+ a -1 b))
--> 3.3306690738754696e-016
--> 4.440892098500626e-016
(let ((a (expt 2 -1074)) (b 0.25)) (* a 4 b))
--> 5e-324
--> 0.0
3. Mulitiplication/Division optimization sometimes don't consider
floating point operators.
Examples.
(let ((a 1.0)) (* a 0))
--> 0.0
--> 0
(let ((a 1.0)) (* a 2.0 0))
--> 0.0
--> 0
(let ((a 1.0)) (/ 0 a))
--> 0.0
--> 0
(let ((a 1.0)) (/ 3 a 2))
--> 1.5
--> 1.0
4. In division, optimizing -1 twice and cause erroneous results.
Examples.
(/ 3 -1)
--> -3
--> 3
Attached files are rewrittren version and too much changed, so it is
possibly just for references (At least, alias functions are not
treated well, and not comprehensively tested).
bytecomp-patch.el -- contain only new and modified symbols/functions.
byte-opt-test.el -- test function that shows interpreter/original/revised
results.
test.log -- test result using above files.
byte-opt.el bytecomp.el -- changed files to replace.
Regards,
Shigeru
[bc.tgz (application/x-gzip, attachment)]
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #10 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
> Hello,
>
> Current byte compiler has potential problems in arithmetic operations.
> Examples are all on Intel 32-bit. Result may occur in other
> environments.
Good work catching these problems. I've committed your bytecomp.el
changes into CVS. I'm double-checking your changes to byte-opt.el, and
will commit them in later if no problems occur.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #15 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
Hi Shigeru,
I've been looking through your changes to byte-opt.el. They look good,
but some of the changes are a little too agressive for my tastes, so
close to pretest.
Could you separate out the byte-optimize-*-functions part of the patch?
A mistake in any of these lists could lead to some hard-to-track errors.
If in doubt, let's simply not perform the optimization for now. We can
apply these changes after the release.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #20 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
Hi, Chong,
I agree it's too aggressive. I'd just sought for the best.
> Could you separate out the byte-optimize-*-functions part of the patch?
They are mutually affected. So I'll make and send a patch of
byte-opt.el that includes minimal changes to the latest CVS. It is
necessary because the current byte-opt.el still has problems I
pointed. It will take a few days.
Is it ok?
Regards,
Shigeru
----- Original Message -----
From: "Chong Yidong" <cyd <at> stupidchicken.com>
To: "Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
Cc: <1334 <at> debbugs.gnu.org>
Sent: Saturday, November 15, 2008 8:10 AM
Subject: Re: 23.0.60; bug of bytecomp arithmetic operations
> Hi Shigeru,
>
> I've been looking through your changes to byte-opt.el. They look good,
> but some of the changes are a little too agressive for my tastes, so
> close to pretest.
>
> Could you separate out the byte-optimize-*-functions part of the patch?
> A mistake in any of these lists could lead to some hard-to-track errors.
> If in doubt, let's simply not perform the optimization for now. We can
> apply these changes after the release.
----- Original Message -----
From: "Chong Yidong" <cyd <at> stupidchicken.com>
To: "Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
Cc: <1334 <at> debbugs.gnu.org>
Sent: Saturday, November 15, 2008 8:10 AM
Subject: Re: 23.0.60; bug of bytecomp arithmetic operations
> Hi Shigeru,
>
> I've been looking through your changes to byte-opt.el. They look good,
> but some of the changes are a little too agressive for my tastes, so
> close to pretest.
>
> Could you separate out the byte-optimize-*-functions part of the patch?
> A mistake in any of these lists could lead to some hard-to-track errors.
> If in doubt, let's simply not perform the optimization for now. We can
> apply these changes after the release.
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #25 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com> writes:
>> Could you separate out the byte-optimize-*-functions part of the patch?
>
> They are mutually affected. So I'll make and send a patch of
> byte-opt.el that includes minimal changes to the latest CVS. It is
> necessary because the current byte-opt.el still has problems I
> pointed. It will take a few days.
>
> Is it ok?
That would be great. Thanks!
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #30 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Hello, Chong and everybody,
After bytecomp.el is revised, problems remains as follows;
1. Operations are all compiled to binary operations. It may cause
overflows or truncations in floating point data operations.
==> solved.
2. Most integer constants are moved to the end of expressions and
pre-calculated at compile time. Changing of order may cause different
result from original expressions.
(In other words, `byte-optimize-delay-constants-math' should not be called)
==> In multiplication/division, problems become not to occur.
I suppose it is because difference of precision/scale size in
elisp, execution level, processor internal (elisp < C < processor)
take over the issue.
(let ((a (expt 2 -1074)) (b 0.125))
(list (* a b 8) (* (* a b) 8)))
--> (5e-324 0.0)
I can't find the bad case so far. So, in multiplication and
division, I suppose, at least now, changing calculation order
is allowable and leave `byte-optimize-delay-constants-math'.
Addition/Subtraction still show this problem.
3. Mulitiplication/Division optimization sometimes don't consider
floating point operators.
==> Add patterns.
Examples.
(let ((a most-positive-fixnum) (b 2.0)) (* a 2 b))
--> 1073741820.0
--> -4.0
(let ((a 3) (b 2)) (/ a b 1.0))
--> 1.5
--> 1
4. In division, optimizing -1 twice and cause erroneous results.
==> Easy.
To get all examples at a glance, see the attached
`byte-test-minimal.el' or its log file.
Changing policy / plan
* Change functions byte-optimize-plus, byte-optimize-minus,
byte-optimize-multiply, byte-optimize-divide.
* All modifications are closed to the function itself. Don't add other
functions, symbols.
* Don't call `byte-optimize-delay-constants-math' in plus, minus
operations. Remain to call it in multiplication, division operations.
* Call `byte-optimize-predicate' at the last as in minus operation.
This will optimize expressions that all arguments are constant to
constant values.
* Consider frequency or possibility.
** Remove/Abandon some optimizations.
*** Most optimizations that need floating point data result.
**** Zero in operands of multiplication or division (first
operand). This case seems rare. If you do something, it's like
below,
Multiplication:
(cond ((or (memql 0.0 (cdr form))
(and (eq 0 last) (memq t (mapcar #'floatp (cdr form)))))
(setq form (nconc (list 'progn)
(delq 0 (mapcar (lambda (x)
(if (or (numberp x) (symbolp x))
0
x))
(cdr form)))
(list 0.0))))
Division:
(cond ((or (eql (cadr form) 0.0)
(and (eq (cadr form) 0) (memq t (mapcar #'floatp (cddr form)))))
;; This optimization may throw out division by zero error.
(setq form (nconc (list 'progn)
(delq 0 (mapcar (lambda (x)
(if (or (numberp x) (symbolp x))
0
x))
(cdr form)))
(list 0.0))))
((and (eq (cadr form 0) 0) (numberp last) (nthcdr 3 form))
(setq form (byte-compile-butlast form))
)
** Add some optimizations.
*** Optimize addtion/subtraction where their last operand is 1 or
-1 to use `1+', `1-' funcitons. This pattern often appears and
more effective at least in size (byte-add1 vs constant 1).
*** Other small changes.
Files:
ChangeLog
byte-opt.el - modified file.
byte-opt.diff - diff by `diff -c OLD NEW >byte-opt.diff'
byte-test-minimal.el - test script to compare original and revised.
log.summary - sammary output by byte-test-minimal
log.detail - detailed (with disassembled code) output by
byte-test-minimal.
byte-regress-minimal.el - simple coverage test
log.regress - log output of the coverage test
If something is wrong, let me know, please.
Regards,
Shigeru
2008/11/15 Chong Yidong <cyd <at> stupidchicken.com>:
> "Shigeru Fukaya" <shigeru.fukaya <at> gmail.com> writes:
>
>>> Could you separate out the byte-optimize-*-functions part of the patch?
>>
>> They are mutually affected. So I'll make and send a patch of
>> byte-opt.el that includes minimal changes to the latest CVS. It is
>> necessary because the current byte-opt.el still has problems I
>> pointed. It will take a few days.
>>
>> Is it ok?
>
> That would be great. Thanks!
>
[bc2.tgz (application/x-gzip, attachment)]
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #35 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
Thanks. I'm looking through your changes.
! ;; (- 0 x) --> (- x)
! ((and (eq (nth 1 form) 0) (= (length form) 3))
! (setq form (list '- (nth 1 form))))
Shouldn't this be (nth 2 form) on the last line?
Information forwarded to
bug-submit-list <at> lists.donarmstrong.com, Emacs Bugs <bug-gnu-emacs <at> gnu.org>
:
bug#1334
; Package
emacs
.
Full text and
rfc822 format available.
Acknowledgement sent to
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
:
Extra info received and forwarded to list. Copy sent to
Emacs Bugs <bug-gnu-emacs <at> gnu.org>
.
Full text and
rfc822 format available.
Message #40 received at 1334 <at> emacsbugs.donarmstrong.com (full text, mbox):
Hi, Chong,
> Shouldn't this be (nth 2 form) on the last line?
Of course, you are right.
I found I had tested with my older version.
In `byte-regression-test', I should have remove the following line.
(load "byte-opt-minimal")
After above correction, log output contains three errors.
(let ((a 3) (b 2) (c 1.0)) (- 0 a)) --> -3, NG
--> 0
(let ((a 3) (b 2) (c 1.0)) (- 0 c)) --> -1.0, NG
--> 0
(let ((a 3) (b 2) (c 1.0)) (- 0 a)) --> -3, NG
--> 0
Thank you,
- Shigeru
----- Original Message -----
From: "Chong Yidong" <cyd <at> stupidchicken.com>
To: "Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
Cc: <1334 <at> debbugs.gnu.org>
Sent: Friday, November 21, 2008 4:40 PM
Subject: Re: 23.0.60; bug of bytecomp arithmetic operations
> Thanks. I'm looking through your changes.
>
> ! ;; (- 0 x) --> (- x)
> ! ((and (eq (nth 1 form) 0) (= (length form) 3))
> ! (setq form (list '- (nth 1 form))))
>
> Shouldn't this be (nth 2 form) on the last line?
Reply sent to
Chong Yidong <cyd <at> stupidchicken.com>
:
You have taken responsibility.
Full text and
rfc822 format available.
Notification sent to
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
:
bug acknowledged by developer.
Full text and
rfc822 format available.
Message #45 received at 1334-done <at> emacsbugs.donarmstrong.com (full text, mbox):
I've reviewed your patch, and checked most of it into CVS (I took the
liberty of rewording some comments, plus some minor edits).
> *** Optimize addtion/subtraction where their last operand is 1 or
> -1 to use `1+', `1-' funcitons. This pattern often appears and
> more effective at least in size (byte-add1 vs constant 1).
Let's leave this till after the release. It's not clear to me that
there is a significant speed increase from it, and we should try to
restrict the changes to bug fixes for the moment.
Thanks very much for working on this.
Message #46 received at 1334-done <at> emacsbugs.donarmstrong.com (full text, mbox):
>> *** Optimize addtion/subtraction where their last operand is 1 or
>> -1 to use `1+', `1-' funcitons. This pattern often appears and
>> more effective at least in size (byte-add1 vs constant 1).
>
> Let's leave this till after the release. It's not clear to me that
> there is a significant speed increase from it, and we should try to
> restrict the changes to bug fixes for the moment.
I myself was actually irresolute.
But, at least, for three operands I think it it worths
optimizing. For more than three operands, only expectation of
save of storage(for constant 1), and probability of the later
re-optimization induced by decresing of the number of operands.
(+ a b 1)
no optimization optimazation
0 constant + varref a
1 varref a varref b
2 varref b plus
3 constant 1 add1
4 call 3 return
5 return
(+ a b c 1)
0 constant + constant +
1 varref a varref a
2 varref b varref b
3 varref c varref c
4 constant 1 call 3
5 call 4 add1
6 return return
(byte-compile (lambda () (+ a b c 1)))
#[nil "\303\b\t\n\304$\207" [a b c + 1] 5]
#[nil "\303\b\t\n#T\207" [a b c +] 4]
Anyway, please do what you think is best now.
Regards,
Shigeru
2008/11/22 Chong Yidong <cyd <at> stupidchicken.com>:
> I've reviewed your patch, and checked most of it into CVS (I took the
> liberty of rewording some comments, plus some minor edits).
>
>> *** Optimize addtion/subtraction where their last operand is 1 or
>> -1 to use `1+', `1-' funcitons. This pattern often appears and
>> more effective at least in size (byte-add1 vs constant 1).
>
> Let's leave this till after the release. It's not clear to me that
> there is a significant speed increase from it, and we should try to
> restrict the changes to bug fixes for the moment.
>
> Thanks very much for working on this.
>
Message #47 received at 1334-done <at> emacsbugs.donarmstrong.com (full text, mbox):
BTW, it occurs to me that the nice byte compilation test code you have
written should not go to waste.
We have a test/ subdirectory in the Emacs tree, which currently contains
a couple of *-testsuite.el files. If you could get your testcases into
a file into a similar form, we could add them to CVS. Would you be
interested in doing that?
Message #48 received at 1334-done <at> emacsbugs.donarmstrong.com (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I don't see the format well, but tried.
Do the attached as you like, please!
Regards,
Shigeru
----- Original Message -----
From: "Chong Yidong" <cyd <at> stupidchicken.com>
To: "Shigeru Fukaya" <shigeru.fukaya <at> gmail.com>
Cc: <1334-done <at> debbugs.gnu.org>
Sent: Sunday, November 23, 2008 3:50 PM
Subject: Re: 23.0.60; bug of bytecomp arithmetic operations
> BTW, it occurs to me that the nice byte compilation test code you have
> written should not go to waste.
>
> We have a test/ subdirectory in the Emacs tree, which currently contains
> a couple of *-testsuite.el files. If you could get your testcases into
> a file into a similar form, we could add them to CVS. Would you be
> interested in doing that?
[bytecomp-testsuite.el.gz (application/x-gzip, attachment)]
Message #49 received at 1334-done <at> emacsbugs.donarmstrong.com (full text, mbox):
"Shigeru Fukaya" <shigeru.fukaya <at> gmail.com> writes:
> Do the attached as you like, please!
Thanks. I've added it to the test/ directory.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> emacsbugs.donarmstrong.com
.
(Sun, 28 Dec 2008 15:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 16 years and 233 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.