bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30020: floating point unboxing regression in 2.2.3


From: Thompson, David
Subject: bug#30020: floating point unboxing regression in 2.2.3
Date: Sun, 7 Jan 2018 22:16:17 -0500

Hello,

Guile 2.2.3 seems to have lost some of the abilities that Guile 2.2.2
had wrt unboxing floats.  Here's a simple procedure to show the
problem. It simply adds the first two elements of an f32vector:

    (define (add-two-floats bv)
      (+ (f32vector-ref bv 0) (f32vector-ref bv 1)))

Here's the disassembly from 2.2.2 (note that f64->scm appears only once):

    Disassembly of #<procedure add-two-floats (bv)> at #x7efef4006230:

       0    (assert-nargs-ee/locals 2 1)    ;; 3 slots (1 arg)    at
(unknown file):22:0
       1    (load-u64 2 0 0)                                      at
(unknown file):23:26
       4    (bv-f32-ref 2 1 2)
       5    (load-u64 0 0 4)                                      at
(unknown file):23:47
       8    (bv-f32-ref 1 1 0)
       9    (fadd 2 2 1)                                          at
(unknown file):23:23
      10    (f64->scm 1 2)
      11    (handle-interrupts)
      12    (return-values 2)               ;; 1 value

And here is 2.2.3:

    Disassembly of #<procedure add-two-floats (bv)> at #x2457140:

       0    (assert-nargs-ee/locals 2 1)    ;; 3 slots (1 arg)    at
(unknown file):29:0
       1    (load-u64 2 0 0)                                      at
(unknown file):30:26
       4    (bv-f32-ref 2 1 2)
       5    (f64->scm 2 2)
       6    (load-u64 0 0 4)                                      at
(unknown file):30:47
       9    (bv-f32-ref 1 1 0)
      10    (f64->scm 1 1)
      11    (scm->f64 2 2)                                        at
(unknown file):30:23
      12    (scm->f64 1 1)
      13    (fadd 2 2 1)
      14    (f64->scm 1 2)
      15    (handle-interrupts)
      16    (return-values 2)               ;; 1 value

2.2.3 is reading unboxed floats from the bytevector, boxing them,
unboxing them, then calling fadd.  The result is that some formerly
well optimized code of mine that generated little to no garbage is now
generating lots of garbage.  Is this intentional due to the
"instruction explosion" work going on is it a legitimate bug?

Thanks,

- Dave





reply via email to

[Prev in Thread] Current Thread [Next in Thread]