GNU bug report logs - #30020
floating point unboxing regression in 2.2.3

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: "Thompson, David" <dthompson2 <at> worcester.edu>
Subject: bug#30020: closed (Re: bug#30020: floating point unboxing
 regression in 2.2.3)
Date: Mon, 11 Jun 2018 14:29:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#30020: floating point unboxing regression in 2.2.3

which was filed against the guile package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 30020 <at> debbugs.gnu.org.

-- 
30020: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30020
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Mark H Weaver <mhw <at> netris.org>
To: "Thompson\, David" <dthompson2 <at> worcester.edu>
Cc: Andy Wingo <wingo <at> pobox.com>, 30020-done <at> debbugs.gnu.org
Subject: Re: bug#30020: floating point unboxing regression in 2.2.3
Date: Mon, 11 Jun 2018 10:26:50 -0400

Mark H Weaver <mhw <at> netris.org> writes:

> I did the moral equivalent of a git bisect, and found the culprit:
>
>   commit d4883307ca64a7028b9a6cd072974437306c19d3
>   Author: Andy Wingo <wingo <at> pobox.com>
>   Date:   Thu Nov 30 10:41:45 2017 +0100
>
>   Minor CSE run-time optimization
>
>   * module/language/cps/cse.scm (compute-equivalent-subexpressions): Minor
>   optimization to reduce the size of equivalent expression keys, and to
>   avoid some work if an expression has no key.
>
> Fortunately, this commit can be reverted in isolation without any
> difficulty, and apparently without any negative consequences.  If a
> better solution isn't found soon, perhaps that's what we should do.

I pushed commit df93752479ab88446f5db4b1d6ebf53a85c7593f to the
stable-2.2 branch, which reverts the above commit.  I'm closing this
bug, but feel free to reopen if there are still issues to resolve.

     Thanks,
       Mark

[Message part 3 (message/rfc822, inline)]

From: "Thompson, David" <dthompson2 <at> worcester.edu>
To: bug-guile <at> gnu.org
Subject: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.