Guile CSE elimination of record accessor?

Guile CSE elimination of record accessor?

[Simon Tournier]

Hi,

In Guile module (ice-9 vlist), one reads:

--8<---------------cut here---------------start------------->8---
;; Asserting that something is a vlist is actually a win if your next
;; step is to call record accessors, because that causes CSE to
;; eliminate the type checks in those accessors.
;;
(define-inlinable (assert-vlist val)
  (unless (vlist? val)
    (throw 'wrong-type-arg
           #f
           "Not a vlist: ~S"
           (list val)
           (list val))))

[...]

(define (vlist-head vlist)
  "Return the head of VLIST."
  (assert-vlist vlist)
  (let ((base   (vlist-base vlist))
        (offset (vlist-offset vlist)))
    (block-ref (block-content base) offset)))
--8<---------------cut here---------------end--------------->8---

Other said, the argument ’vlist’ is “type-checked” with ’assert-vlist’
and thus that is exploited by Guile compiler, if I understand correctly
the comment.

The first question is: is it still correct?  Because this module had
been implemented before many Guile compiler improvements.


The second question, if the comment above is still valid, is: could we
also “win” for some record inside Guix source code?

Concretely, one example about the record <package>, there is some
procedures such that:

--8<---------------cut here---------------start------------->8---
(define* (package->manifest-entry package #:optional (output "out")
                                  #:key (parent (delay #f))
                                  (properties (default-properties package)))
  "Return a manifest entry for the OUTPUT of package PACKAGE."
  ;; For each dependency, keep a promise pointing to its "parent" entry.
  (letrec* ((deps  (map (match-lambda
                          ((label package)
                           (package->manifest-entry package
                                                    #:parent (delay entry)))
                          ((label package output)
                           (package->manifest-entry package output
                                                    #:parent (delay entry))))
                        (package-propagated-inputs package)))
            (entry (manifest-entry
                     (name (package-name package))
                     (version (package-version package))
                     (output output)
                     (item package)
                     (dependencies (delete-duplicates deps))
                     (search-paths
                      (package-transitive-native-search-paths package))
                     (parent parent)
                     (properties properties))))
    entry))
--8<---------------cut here---------------end--------------->8---

which fits the comment above: a record as argument and record accessor
call.

And that could also be applied to other records, I guess.


Any answers, explanations or references are very welcome. :-)

Cheers,
simon

PS: Raining day and weird pastime… diving into Guile source code. ;-)

Re: Guile CSE elimination of record accessor?

[Andy Wingo]

Hi :)

On Sat 27 Apr 2024 19:04, Simon Tournier <zimon.toutoune@gmail.com> writes:

> In Guile module (ice-9 vlist), one reads:
>
> ;; Asserting that something is a vlist is actually a win if your next
> ;; step is to call record accessors, because that causes CSE to
> ;; eliminate the type checks in those accessors.
> ;;
> (define-inlinable (assert-vlist val)
>   (unless (vlist? val)
>     (throw 'wrong-type-arg
>            #f
>            "Not a vlist: ~S"
>            (list val)
>            (list val))))
>
> [...]
>
> (define (vlist-head vlist)
>   "Return the head of VLIST."
>   (assert-vlist vlist)
>   (let ((base   (vlist-base vlist))
>         (offset (vlist-offset vlist)))
>     (block-ref (block-content base) offset)))
>
>
> Other said, the argument ’vlist’ is “type-checked” with ’assert-vlist’
> and thus that is exploited by Guile compiler, if I understand correctly
> the comment.
>
> The first question is: is it still correct?  Because this module had
> been implemented before many Guile compiler improvements.

No, the comment is incorrect.  The type check on whatever accessor is
called first (unspecified in scheme; probably we should just bite the
bullet and do predictable left-to-right semantics, as racket does) will
dominate the rest and eliminate those checks.  The assert-type is
unnecessary.

To see this, do ,optimize-cps at the repl, and count the number of
e.g. struct? checks with and without the assert-vlist.  There is only
one, either way.  (A type check is a heap-object? check, then struct?,
then get the vtable, then check against the global variable <vlist>.
All of these duplicates get eliminated.)

> PS: Raining day and weird pastime… diving into Guile source code. ;-)

:)

Cheers

Andy

Re: Guile CSE elimination of record accessor?

[Simon Tournier]

Hi Andy,

Thanks for the explanations.

On mar., 30 avril 2024 at 16:43, Andy Wingo <wingo@igalia.com> wrote:

>> The first question is: is it still correct?  Because this module had
>> been implemented before many Guile compiler improvements.
>
> No, the comment is incorrect.  The type check on whatever accessor is
> called first (unspecified in scheme; probably we should just bite the
> bullet and do predictable left-to-right semantics, as racket does) will
> dominate the rest and eliminate those checks.  The assert-type is
> unnecessary.

Good to know.

> To see this, do ,optimize-cps at the repl, and count the number of
> e.g. struct? checks with and without the assert-vlist.  There is only
> one, either way.

Hum, I am not sure to understand how to use ,optimize-cps at the repl.
Naively, I get:

--8<---------------cut here---------------start------------->8---
scheme@(guile-user)> ,use(ice-9 vlist)
scheme@(guile-user)> ,optimize-cps (vlist-cons 'foo vlist-null)
L0:                                           ;              at <unknown>:102:14
  v0 := self
  L1(...)
L1:
  receive()
  v1 := current-module()                      ; mod While executing meta-command:
In procedure +: Wrong type argument in position 1: #f
--8<---------------cut here---------------end--------------->8---

Since ’,help compile’ reads,

    ,optimize-cps EXP         [,optx] - Run the CPS optimizer on a piece of code and print the result.

I assume that I do not feed with the correct expression EXP.  What would
be the invocation?


>                   (A type check is a heap-object? check, then struct?,
> then get the vtable, then check against the global variable <vlist>.
> All of these duplicates get eliminated.)

Ah yeah, it makes sense. :-)

Cheers,
simon