[Sbcl-devel] Problem inlining nested calls to same function
Nikodemus Siivola
(defun foo (x y)
(cons x y))
(defun bar (x)
(foo (foo x x) (foo x x)))
(disassemble 'bar)
Disassembly shows a full call to FOO. I'm not yet sure why one call
doesn't get converted properly, so if someone has insights to offer,
they are very welcome. This doesn't seem to be a new bug, but
something coming all the way from CMUCL heritage.
Cheers,
-- Nikodemus
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Sbcl-devel mailing list
Sbcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-devel
Marco Antoniotti
--
Marco Antoniotti
Raymond Toy (RT/EUS)
> (declaim (inline foo))
> (defun foo (x y)
> (cons x y))
>
> (defun bar (x)
> (foo (foo x x) (foo x x)))
>
> (disassemble 'bar)
>
> Disassembly shows a full call to FOO. I'm not yet sure why one call
> doesn't get converted properly, so if someone has insights to offer,
> they are very welcome. This doesn't seem to be a new bug, but
> something coming all the way from CMUCL heritage.
Wild guess: The compiler thinks a tail-call to foo is better than
inlining foo.
Ray
Nikodemus Siivola
<raymo...@ericsson.com> wrote:
> Nikodemus Siivola wrote:
>>
>> (declaim (inline foo))
>> (defun foo (x y)
>> (cons x y))
>>
>> (defun bar (x)
>> (foo (foo x x) (foo x x)))
>>
>> (disassemble 'bar)
>>
>> Disassembly shows a full call to FOO. I'm not yet sure why one call
>> doesn't get converted properly, so if someone has insights to offer,
>> they are very welcome. This doesn't seem to be a new bug, but
>> something coming all the way from CMUCL heritage.
>
> Wild guess: The compiler thinks a tail-call to foo is better than inlining
> foo.
Fixed in 1.0.22.13. I didn't check, but I suspect the same fix may be
applicable to CMUCL as well.
Cheers,
-- Nikodemus
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Raymond Toy
> On Tue, May 6, 2008 at 9:33 PM, Raymond Toy (RT/EUS)
> <raymo...@ericsson.com> wrote:
>> Nikodemus Siivola wrote:
>>> (declaim (inline foo))
>>> (defun foo (x y)
>>> (cons x y))
>>>
>>> (defun bar (x)
>>> (foo (foo x x) (foo x x)))
>>>
>>> (disassemble 'bar)
>>>
>>> Disassembly shows a full call to FOO. I'm not yet sure why one call
>>> doesn't get converted properly, so if someone has insights to offer,
>>> they are very welcome. This doesn't seem to be a new bug, but
>>> something coming all the way from CMUCL heritage.
>> Wild guess: The compiler thinks a tail-call to foo is better than inlining
>> foo.
>
> Fixed in 1.0.22.13. I didn't check, but I suspect the same fix may be
> applicable to CMUCL as well.
Interesting. The current version of cmucl actually inlines foo. I was
kind of expecting it not to inline it, just like sbcl.
But I'm keeping this message in case I do find an inline issue.
Thank for the info!
Ray
Nikodemus Siivola
> Interesting. The current version of cmucl actually inlines foo. I was
> kind of expecting it not to inline it, just like sbcl.
That is interesting! Looking at the CMUCL source, CMUCL does exactly
what SBCL used to do in RECOGNIZE-KNOWN-CALL. I'm not 100% sure, but I
think CMUCL doesn't run into the same problem here thanks to it's use
of IR1-CONVERT-LAMBDA-FOR-DEFUN.
Cheers,
-- Nikodemus