Raymond Toy pushed to branch issue-287-clean-up-make-float-aux at cmucl / cmucl
Commits:
4a61aa5f by Carl Shapiro at 2024-03-24T21:57:28+00:00
Apply 1 suggestion(s) to 1 file(s)
- - - - -
1 changed file:
- src/code/reader.lisp
Changes:
=====================================
src/code/reader.lisp
=====================================
@@ -1868,7 +1868,7 @@ the end of the stream."
float-format (read-buffer-to-string)))))))
;; Otherwise the number might fit, so we carefully compute the result.
- (handler-case
+ (handler-case
(with-float-traps-masked (:underflow)
(let* ((ratio (/ (* (expt 10 exponent) number)
divisor))
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/4a61aa5f06e409c041754f3…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/4a61aa5f06e409c041754f3…
You're receiving this email because of your account on gitlab.common-lisp.net.
Raymond Toy pushed to branch issue-275b-signal-float-underflow at cmucl / cmucl
Commits:
45532060 by Raymond Toy at 2024-03-23T14:56:58-07:00
Add tests for float underflows in the reader
- - - - -
1 changed file:
- tests/float.lisp
Changes:
=====================================
tests/float.lisp
=====================================
@@ -212,3 +212,17 @@
;; most-positive-double-float. And a really big single-float.
(assert-error 'reader-error (read-from-string "1.8d308"))
(assert-error 'reader-error (read-from-string "1d999999999")))
+
+(define-test reader.float-underflow
+ (:tag :issues)
+ (lisp::with-float-traps-enabled (:underflow)
+ ;; A denormal
+ (assert-error 'floating-point-underflow
+ (read-from-string "1e-40"))
+ (assert-error 'floating-point-underflow
+ (read-from-string (format nil "~A" least-positive-single-float)))
+ ;; The same for double-floats
+ (assert-error 'floating-point-underflow
+ (read-from-string "1d-308"))
+ (assert-error 'floating-point-underflow
+ (read-from-string (format nil "~A" least-positive-double-float)))))
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/45532060060f711842edbfb…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/45532060060f711842edbfb…
You're receiving this email because of your account on gitlab.common-lisp.net.
Raymond Toy pushed to branch issue-287-clean-up-make-float-aux at cmucl / cmucl
Commits:
9d01b5ca by Raymond Toy at 2024-03-23T12:38:44-07:00
Oops. Need handler-case to catch errors from large numbers.
For large numbers that weren't caught the with the rough check, the
conversion of the large ratio to a float signals a `simple-type-error`
from `coerce`. We need to catch that and signal a `reader-error`.
- - - - -
2 changed files:
- src/code/reader.lisp
- src/i18n/locale/cmucl.pot
Changes:
=====================================
src/code/reader.lisp
=====================================
@@ -1868,17 +1868,20 @@ the end of the stream."
float-format (read-buffer-to-string)))))))
;; Otherwise the number might fit, so we carefully compute the result.
- (with-float-traps-masked (:underflow)
- (let* ((ratio (/ (* (expt 10 exponent) number)
- divisor))
- (result (coerce ratio float-format)))
- (when (and (zerop result) (not (zerop number)))
- ;; The number we've read is so small that it gets
- ;; converted to 0.0, but is not actually zero. Signal an
- ;; error. See CLHS 2.3.1.1.
- (%reader-error stream _"Number not representable as a ~S: ~S"
- float-format (read-buffer-to-string)))
- result)))
+ (handler-case
+ (with-float-traps-masked (:underflow)
+ (let* ((ratio (/ (* (expt 10 exponent) number)
+ divisor))
+ (result (coerce ratio float-format)))
+ (when (and (zerop result) (not (zerop number)))
+ ;; The number we've read is so small that it gets
+ ;; converted to 0.0, but is not actually zero. Signal an
+ ;; error. See CLHS 2.3.1.1.
+ (error "Underflow"))
+ result))
+ (error ()
+ (%reader-error stream _"Number not representable as a ~S: ~S"
+ float-format (read-buffer-to-string)))))
(defun make-ratio (stream)
=====================================
src/i18n/locale/cmucl.pot
=====================================
@@ -8731,10 +8731,6 @@ msgstr ""
msgid "Number not representable as a ~S: ~S"
msgstr ""
-#: src/code/reader.lisp
-msgid "Underflow"
-msgstr ""
-
#: src/code/reader.lisp
msgid "Invalid ratio: ~S/~S"
msgstr ""
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/9d01b5ca1b1e93e964f388c…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/9d01b5ca1b1e93e964f388c…
You're receiving this email because of your account on gitlab.common-lisp.net.
Raymond Toy pushed to branch master at cmucl / cmucl
Commits:
04225fe5 by Raymond Toy at 2024-03-22T09:55:30-07:00
Fix #284: Optimize signed-byte-32-int-len VOP
Take advantage of the fact that `BSR` will not modify the destination
register if the source is 0. We already use this idea for the
`unsigne-byte-32-int-len` VOP, so let's do the same for this VOP. It
saves an instruction and a branch.
- - - - -
274feae4 by Raymond Toy at 2024-03-22T09:58:37-07:00
Update release notes for #284
- - - - -
b68de43f by Raymond Toy at 2024-03-22T10:02:07-07:00
Remove comment to rtfm for signed-byte-32-len
Not sure what the comment is referring too. It came in the huge
commit [c0c98ded6c]. I think the implementation is correct.
- - - - -
4ffad32e by Raymond Toy at 2024-03-22T13:08:11-07:00
Optimize unsigned-byte-32-int-len some more
Take advantage of the fact that BSR actually moves the src to the dst
register when the src is 0. The Intel docs don't says this, but gcc,
LLVM, and MSVC compilers basically assume this when generating code
that uses BSR.
- - - - -
5538e622 by Raymond Toy at 2024-03-22T19:48:37-07:00
Add some tests for integer-length of signed and unsigned 32-bit ints
Define functions that use the VOPs for integer-length of signed and
unsigned 32-bit integers.
Test a few "interesting" integers with these functions.
- - - - -
d82f9b92 by Raymond Toy at 2024-03-23T03:09:38+00:00
Merge branch 'issue-284-optimize-signed-byte-32-int-len-vop' into 'master'
Fix #284: Optimize signed and unsigned 32-bit integer length VOPs
Closes #284
See merge request cmucl/cmucl!195
- - - - -
3 changed files:
- src/compiler/x86/arith.lisp
- src/general-info/release-21f.md
- + tests/integer.lisp
Changes:
=====================================
src/compiler/x86/arith.lisp
=====================================
@@ -731,7 +731,6 @@
DONE))
-;;; note documentation for this function is wrong - rtfm
(define-vop (signed-byte-32-len)
(:translate integer-length)
(:note _N"inline (signed-byte 32) integer-length")
@@ -747,12 +746,9 @@
(inst not res)
POS
(inst bsr res res)
- (inst jmp :z zero)
+ (inst jmp :z DONE)
(inst inc res)
(inst shl res 2)
- (inst jmp done)
- ZERO
- (inst xor res res)
DONE))
(define-vop (unsigned-byte-32-len)
@@ -764,12 +760,11 @@
(:results (res :scs (any-reg)))
(:result-types positive-fixnum)
(:generator 30
- (move res arg)
;; The Intel docs say that BSR leaves the destination register
- ;; undefined if the source is 0. But AMD64 says the destination
- ;; register is unchanged. This also appears to be the case for
- ;; GCC and LLVM.
- (inst bsr res res)
+ ;; undefined if the source is 0. However, gcc, LLVM, and MSVC
+ ;; generate code that pretty much says BSR basically moves the
+ ;; source to the destination if the source is 0.
+ (inst bsr res arg)
(inst jmp :z DONE)
;; The result of BSR is one too small for what we want, so
;; increment the result.
=====================================
src/general-info/release-21f.md
=====================================
@@ -61,6 +61,7 @@ public domain.
least-positive-float
* ~~#278~~ Add some more debugging prints to gencgc
* ~~#283~~ Add VOP for `integer-length` for `(unsigned-byte 32)` arg.
+ * ~~#284~~ Microoptimize `signed-byte-32-int-len` VOP for x86.
* Other changes:
* Improvements to the PCL implementation of CLOS:
* Changes to building procedure:
=====================================
tests/integer.lisp
=====================================
@@ -0,0 +1,38 @@
+;; Tests of integer functions
+
+(defpackage :integer-tests
+ (:use :cl :lisp-unit))
+
+(in-package "INTEGER-TESTS")
+
+;; Simple functions for testing INTEGER-LENGTH for numbers of type
+;; (unsigned-byte 32) and (signed-byte 32).
+(defun integer-length-u32 (n)
+ (declare (type (unsigned-byte 32) n))
+ (integer-length n))
+
+(defun integer-length-s32 (n)
+ (declare (type (signed-byte 32) n))
+ (integer-length n))
+
+(define-test integer-length.unsigned-byte-32
+ (:tag :issues)
+ (assert-equal 0 (integer-length-u32 0))
+ (assert-equal 1 (integer-length-u32 1))
+ (assert-equal 31 (integer-length-u32 #x70000000))
+ (assert-equal 31 (integer-length-u32 #x7fffffff))
+ (assert-equal 32 (integer-length-u32 #xffffffff)))
+
+(define-test integer-length.signed-byte-32
+ (:tag :issues)
+ (assert-equal 0 (integer-length-s32 0))
+ (assert-equal 1 (integer-length-s32 1))
+ (assert-equal 31 (integer-length-s32 #x70000000))
+ (assert-equal 31 (integer-length-s32 #x7fffffff))
+ (assert-equal 0 (integer-length-s32 -1))
+ (assert-equal 1 (integer-length-s32 -2))
+ (assert-equal 31 (integer-length-s32 #x-70000000))
+ (assert-equal 31 (integer-length-s32 #x-7fffffff))
+ (assert-equal 31 (integer-length-s32 #x-80000000)))
+
+
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/compare/62c23d276620926d311ea9…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/compare/62c23d276620926d311ea9…
You're receiving this email because of your account on gitlab.common-lisp.net.
Raymond Toy pushed to branch issue-284-optimize-signed-byte-32-int-len-vop at cmucl / cmucl
Commits:
4ffad32e by Raymond Toy at 2024-03-22T13:08:11-07:00
Optimize unsigned-byte-32-int-len some more
Take advantage of the fact that BSR actually moves the src to the dst
register when the src is 0. The Intel docs don't says this, but gcc,
LLVM, and MSVC compilers basically assume this when generating code
that uses BSR.
- - - - -
1 changed file:
- src/compiler/x86/arith.lisp
Changes:
=====================================
src/compiler/x86/arith.lisp
=====================================
@@ -760,12 +760,11 @@
(:results (res :scs (any-reg)))
(:result-types positive-fixnum)
(:generator 30
- (move res arg)
;; The Intel docs say that BSR leaves the destination register
- ;; undefined if the source is 0. But AMD64 says the destination
- ;; register is unchanged. This also appears to be the case for
- ;; GCC and LLVM.
- (inst bsr res res)
+ ;; undefined if the source is 0. However, gcc, LLVM, and MSVC
+ ;; generate code that pretty much says BSR basically moves the
+ ;; source to the destination if the source is 0.
+ (inst bsr res arg)
(inst jmp :z DONE)
;; The result of BSR is one too small for what we want, so
;; increment the result.
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/4ffad32e09195013f27e6e3…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/4ffad32e09195013f27e6e3…
You're receiving this email because of your account on gitlab.common-lisp.net.
Raymond Toy pushed to branch issue-284-optimize-signed-byte-32-int-len-vop at cmucl / cmucl
Commits:
b68de43f by Raymond Toy at 2024-03-22T10:02:07-07:00
Remove comment to rtfm for signed-byte-32-len
Not sure what the comment is referring too. It came in the huge
commit [c0c98ded6c]. I think the implementation is correct.
- - - - -
1 changed file:
- src/compiler/x86/arith.lisp
Changes:
=====================================
src/compiler/x86/arith.lisp
=====================================
@@ -731,7 +731,6 @@
DONE))
-;;; note documentation for this function is wrong - rtfm
(define-vop (signed-byte-32-len)
(:translate integer-length)
(:note _N"inline (signed-byte 32) integer-length")
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/b68de43fee9f4c6b508597e…
--
View it on GitLab: https://gitlab.common-lisp.net/cmucl/cmucl/-/commit/b68de43fee9f4c6b508597e…
You're receiving this email because of your account on gitlab.common-lisp.net.