Smarter recursive inlining

Attached patch makes recursive functions inline without complaints: it
keeps track what argument type a call has been expanded with, and
refuses to re-expand for the same argument types.

It hasn't been tested much at all yet, but people with codebases that
might benefit from this are encouraged to give it a whirl.

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Smarter recursive inlining

On 2012-04-03, at 11:43 AM, Nikodemus Siivola wrote:

> Attached patch makes recursive functions inline without complaints: it
> keeps track what argument type a call has been expanded with, and
> refuses to re-expand for the same argument types.

LVAR-TYPE can expand to pretty much any CL type, right? The check should probably widen the argument types
first, to ensure a finite universe. Restricting ourselves to named or primitive types sounds like it
should be good enough.

Paul Khuong
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

Re: Smarter recursive inlining

On 3 April 2012 20:03, Paul Khuong <pvk <at> pvk.ca> wrote:

> LVAR-TYPE can expand to pretty much any CL type, right? The check should
> probably widen the argument types first, to ensure a finite universe.
> Restricting ourselves to named or primitive types sounds like it should be
> good enough.

Constants-lvar types as-is and the rest widened?

Cheers,

 -- Nikodemus

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Smarter recursive inlining

On 2012-04-03, at 2:50 PM, Nikodemus Siivola wrote:

> On 3 April 2012 20:03, Paul Khuong <pvk <at> pvk.ca> wrote:
> 
>> LVAR-TYPE can expand to pretty much any CL type, right? The check should
>> probably widen the argument types first, to ensure a finite universe.
>> Restricting ourselves to named or primitive types sounds like it should be
>> good enough.
> 
> Constants-lvar types as-is and the rest widened?

CL-USER> (sb-kernel:%simple-fun-type (lambda (x)
                                       (declare (type (eql 1) x))
                                       (1+ x)))
(FUNCTION ((INTEGER 1 1)) (VALUES (INTEGER 2 2) &OPTIONAL))

I think we'll need a limit on the number of singleton types as well.

Paul Khuong

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev

Re: Smarter recursive inlining

> Attached patch makes recursive functions inline without complaints: it
> keeps track what argument type a call has been expanded with, and
> refuses to re-expand for the same argument types.
>
> It hasn't been tested much at all yet, but people with codebases that
> might benefit from this are encouraged to give it a whirl.
Thanks a lot, it helps a fair bit for compilation.

Attached is a (modified) test case.
I'd have expected (hoped ;) the ($ 4) case to be inlined to a constant 4 in the
code, but what I get instead is this:

    ;;; [40] ($ 4)
   ;  494C:       MOV RBX, [RBX+1]
   ;  4950:       MOV RDX, [RDX-7]
   ;  4954:       MOV RDI, RCX
   ;  4957:       CMP RCX, [RIP-662]         ; :A
   ;  495E:       JEQ L17
   ;  4964:       CMP RCX, [RIP-667]         ; :B
   ;  496B:       JEQ L14
   ;  4971:       CMP RCX, 537919511
   ;  4978:       JNE L13
   ;  497E:       MOV RCX, RDX
   ;  4981:       TEST RCX, RCX
   ;  4984:       JEQ L12
   ;  498A:       MOV RDI, RDX
   ;  498D:       SUB RDI, 2
   ;  4991:       MOV RDX, [RIP-720]         ; :A
   ;  4998:       MOV [R12+208], RBP
   ;  49A0:       MOV R11, [R12+128]

Re: Smarter recursive inlining

On 4 April 2012 01:03, Martin Cracauer <cracauer <at> cons.org> wrote:

> Bombs out for my toy.
>
> First it throws a bunch of warnings about declared integer types not
> matching derived ones, when not justified IMHO (seems to be missing
> previous 'if' statements guarding against the improper value).

Thanks for taking it out for a ride!

Having run more test-cases through it myself, I haven't been able to
yet break things anything near as bad as that, but I have to say that
I've concluded that this is nowhere near sufficient when it comes to
trying to do better with recursive inlines.

For example, I'd expect roughly equivalent code for both:

(compile nil `(lambda (x y)
                (declare (fixnum x y))
                (labels ((foo (x y z)
                           (declare (fixnum x y))
                           (case z
                             (:add
                              (+ x y))
                             (:sub
                              (- x y))
                             (t
                              (if (> x y)
                                  (foo x y :sub)
                                  (foo x y :add))))))

Re: Smarter recursive inlining

Hello Nikodemus,

> Thanks for taking it out for a ride!
You're welcome, it's my problem after all!

> 2. For reasons of type-safety the compiler has to be rather
> conservative when it comes to deriving CONS types -- so it cannot
> figure out anything sensible about (FIRST REST) anyways.
here's another test case that avoids list operations:

    (defun y (x &optional z)
      (labels
        (($ (&optional p1 p2)
           (declare (type (or (integer 0 15) keyword null) p1))
           (declare (type (or (integer 0 15) null) p2))
           (let* ((what (and (keywordp p1) p1))
                  (idx (if (numberp p1) p1 p2)))
             (declare (type (or (integer 0 15) null) idx))
             (declare (type (or keyword null) what))
             (ecase what
               ((:a) (1+ idx))
               ((:b) ($ :a 4))
               ((nil)
                (if (zerop idx)
                  1
                  ($ :a (1- idx))))))))
        (declare (inline $))
        (print ($ x z)) ; disable that for (disassembly 'y) tests
        (print ($ 4))))

Minor cleanups of some tests

Some time ago, I submitted the following patch, or a variant thereof.
Can someone please review and apply it?

1- It removes a number of warnings output when running tests

2- It allows one to define SBCL_HOME, SBCL_CORE, SBCL_RUNTIME,
SBCL_ARGS and/or TEST_DIRECTORY,
 and run tests from an installed SBCL rather than from the source and
build directory.
 This is quite useful to test a package (e.g. RPM) one makes of SBCL

PS: How does one apply for a commit bit to SBCL? And if/when one has
it, what are the testing guidelines before commit?
Is the modern procedure to make pull requests on github or some such?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Guns & bullets don't kill people — blood loss and organ damage kills people.

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Sbcl-devel mailing list
Sbcl-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel

Re: Minor cleanups of some tests

Of course I had forgotten to attach the patch. Here it is.

NB: we use this patch at ITA (by Google) to test the sbcl rpm/deb
packages we build.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
How can you find a person who loves you the way you are,
if you constantly lie about who you are?

On Mon, Apr 9, 2012 at 00:21, Faré <fahree <at> gmail.com> wrote:
> Some time ago, I submitted the following patch, or a variant thereof.
> Can someone please review and apply it?
>
> 1- It removes a number of warnings output when running tests
>
> 2- It allows one to define SBCL_HOME, SBCL_CORE, SBCL_RUNTIME,
> SBCL_ARGS and/or TEST_DIRECTORY,
>  and run tests from an installed SBCL rather than from the source and
> build directory.
>  This is quite useful to test a package (e.g. RPM) one makes of SBCL
>
> PS: How does one apply for a commit bit to SBCL? And if/when one has
> it, what are the testing guidelines before commit?
> Is the modern procedure to make pull requests on github or some such?
>
> —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
> Guns & bullets don't kill people — blood loss and organ damage kills people.

*default-special-bindings*

This patch adds a previously discussed (long time ago)
*default-special-bindings* feature to SBCL,
whereby users can customize which special variables get automatically
bound in a new thread.
This allows some modularity in that a library L can declare such variables
such that application A can use library L inside threads that
infrastructure I spawns
without infrastructure I having to know anything about L, or A having
to intercept the way I spawns threads.

The patch is only lightly tested, but is rather straightforward.

NB: Cleaning up a checkout on a computer to be retired,
I realized these patches had never been pushed upstream.
I had a third patch, but it will hopefully be obsoleted when the
Windows branch is merged.
Any news about the merge? Is there a way I can help?

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
He who refuses to do arithmetic is doomed to talk nonsense.
	— John McCarthy, in his webpage on Progress and Sustainability

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2