unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: "Thompson, David" <dthompson2@worcester.edu>
To: 30020@debbugs.gnu.org
Subject: bug#30020: floating point unboxing regression in 2.2.3
Date: Sun, 7 Jan 2018 22:16:17 -0500	[thread overview]
Message-ID: <CAJ=RwfbKjzs3khOOnSTrR9Fs8wA1aSzr-9V5CPygOrFZJLRG=w@mail.gmail.com> (raw)

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	other threads:[~2018-01-08  3:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08  3:16 Thompson, David [this message]
2018-05-02 14:11 ` bug#30020: floating point unboxing regression in 2.2.3 Thompson, David
2018-05-28  6:21 ` Mark H Weaver
2018-05-28 19:39   ` Thompson, David
2018-06-11 14:26   ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ=RwfbKjzs3khOOnSTrR9Fs8wA1aSzr-9V5CPygOrFZJLRG=w@mail.gmail.com' \
    --to=dthompson2@worcester.edu \
    --cc=30020@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).