Re: Ron Garret considered harmful [Re: DEFSTRUCT and lexical environment]

On Mon, 19 Oct 2009 21:09:42 +0200, Tobias C. Rittweiler wrote:

Tamas K Papp <tkpapp@xxxxxxxxx> writes:

On Mon, 19 Oct 2009 20:27:44 +0200, Tobias C. Rittweiler wrote:

Congratulations for completely missing the point. But, no problem,
I'll help you see it. Try the following:

Maybe I did miss that point - thanks for the examples. You originally
wrote

which means that they try to compile the inlined code with the
optimization settings of the call site. Uhm...

and you were surprised at this. Do you think that his conflicts with
the standard? If so, would you mind explaining why? To me, SBCL did
the "natural" thing in all of you examples, it gave you notes when it
spotted something it could optimize, if given extra declarations.

I don't know if it really conflicts with the standard---that was my
question basically.

But it's surprising that you are not surprised by the behaviour!

(declaim (inline foo))
(defun foo (x y)
(+ x y))

(defun bar (a b)
(declare (optimize speed))
(foo a b))

The body of FOO is compiled within (parts of) the lexical environment of
the _call site_ and not its definition site.

I could not find anything in the standard about this, but my mental
model of what is happening can be best described with a "declaration
context", which in this case is orthogonal to the lexical
environment. But maybe I built this mental model from working a lot
with SBCL, and this is not a reasonable approximation for other
implementations, but I think it is allowed by the standard and it is
the "right thing" to do.

It's a bit contrived, but I'm sure you wouldn't expect

(declaim (inline foo))
(let ((x 1))
(defun foo (y)
(* x y)))

(defun bar (a)
(let ((x -1))
(foo y)))

(bar 42)

to return -42 rather than 42.

Certainly. (I guess there is a typo in the argument of bar, but I see
what you mean). But I would expect -42 only if I thought of inlining
as a macro expansion, which I don't. BTW, SBCL won't even inline foo
for you, complaining that it is to "hairy". Again, this is in line
(no pun) with my expectations about how inline should behave: it
should be an expansion that is semantically equivalent to calling the
function, and it should only happen when it makes sense to the
compiler from an efficiency point of view.

Also, I wonder why SBCL doesn't just use the constant 1 for x in foo and
inline the whole thing, but maybe that would be too much to expect and I
don't mind if SBCL's maintainers concentrate their efforts on optimizing
more realistic examples.

Sorry for missing your initial point, and thanks for your patience.

Tamas
.

Relevant Pages

  • Re: inline function call
    ... > Can I call a function in python inline, so that the python byte compiler ... called with a and b of int type, then a special version of foo is compiled ...
    (comp.lang.python)
  • Re: inline function call
    ... >> Can I call a function in python inline, so that the python byte compiler ... Inlining is putting code to accomplish what foo does in place of the foo call. ... This could be achieved by a custom import function that would capture the AST ... of foo and bar, and extracting that from the AST and modifying the rest of the ...
    (comp.lang.python)
  • Re: calloc.... Why?
    ... >> And using references doesn't make the optimizer's job any ... >and registers), but when the function's inline, the stack ... The compiler can choose to inline ... int foo = 10; ...
    (comp.lang.cpp)
  • Re: Automatically stylizing function/variable names?
    ... foo three ... bar four ... However, he's made it fairly clear that this is not what he wants, because it requires commands in the inline text. ...
    (comp.text.tex)
  • Re: inline
    ... >I have function defined as inline in header file. ... When linking as static lib, ... Class definition + inline function definition of "foo" ...
    (microsoft.public.vc.language)