Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A specific wording in INLINE. #54

Open
jcguu95 opened this issue May 20, 2024 · 5 comments
Open

A specific wording in INLINE. #54

jcguu95 opened this issue May 20, 2024 · 5 comments

Comments

@jcguu95
Copy link

jcguu95 commented May 20, 2024

CLHS: Declaration INLINE, NOTINLINE says

inline specifies that it is desirable for the compiler to produce inline calls to the functions named by function-names [..]

This is a good enough description, but some reader may wonder whether this has effect too on the function object obtained at read time. It would be more accurate to say

inline specifies that it is desirable for the compiler to produce inline calls to the functions named by function-names at the call sites where the function-name is explicitly used [..]

@Bike
Copy link
Member

Bike commented May 22, 2024

I think that is too restrictive. It would for example be okay for a compiler to inline foo in (funcall 'foo ...), or even in (mapcar 'foo ...). Implementations actually do both of those already, even though there is not a call to foo in the code in a direct sense.

@jcguu95
Copy link
Author

jcguu95 commented May 25, 2024

I may be confused with what call sites mean. I thought (funcall 'foo ...) could also be considered a call site of foo. I do intend to include funcall, mapcar, and their friends. Is there a more accurate term for this?

@Bike
Copy link
Member

Bike commented May 26, 2024

Not sure. "call site" is not a glossary term.

What exactly is it that is not affected by inline in this proposal? The actual semantic effect of inlining is very broad (3.2.2.3):

[The file compiler may assume that a] call within a file to a named function that is defined in the same file refers to that function, unless that function has been declared notinline. The consequences are unspecified if functions are redefined individually at run time or multiply defined in the same file.

The second sentence, in particular, gives the compiler very broad discretion since it doesn't have to worry about redefinition in any context, including use of #'/function.

Is the idea of this proposal to clarify that, for example in

(declaim (inline foo))
(defun foo ...)

(defun bar ... (eq #'foo (fdefinition 'foo)))

the comparison has to be true?

@jcguu95
Copy link
Author

jcguu95 commented May 26, 2024

What worries me about the current description is illustrated in the following example.

(declaim (inline foo))
(defun foo () 0)
(defvar bar #'foo)
(defun baz () (funcall #.bar))

Should (funcall #.bar) be inlined? At read-time, it provides the same function object as that pointed by the name FOO. Should (declaim (inline foo)) causes an inlining of that part because it resolves to the same function object, or should it not causes an inlining of that part because that function object at that "code site" isn't obtained from the name foo?

@Bike
Copy link
Member

Bike commented May 26, 2024

This code seems... unlikely. And even if it did show up somewhere, it's invalid. Without some eval-when, foo is not available at compile time (assuming this is all in one compilation unit). Even with eval-when, it would probably be invalid because the function object referenced by baz is not serializable. And outside of a compilation unit, what does it matter? It's unlikely that a literal function object will ever be inlined, but even if it was, this would be impossible to determine by a user within the standard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants