Mercurial > hg > xemacs-beta
comparison lisp/bytecomp.el @ 5577:0b6e7ae1e78f
Update a comment with a better understanding of the optimizer, bytecomp.el
lisp/ChangeLog addition:
2011-10-04 Aidan Kehoe <kehoea@parhasard.net>
* bytecomp.el (byte-compile-funcall):
Correct a comment here, explaining why the optimizer doesn't
expand (funcall #'(lambda ...)) in some contexts with inline
labels, and why it's reasonable to do it here.
| author | Aidan Kehoe <kehoea@parhasard.net> |
|---|---|
| date | Tue, 04 Oct 2011 09:02:14 +0100 |
| parents | 89cb6a66a61f |
| children | 3e621ba12d36 |
comparison
equal
deleted
inserted
replaced
| 5576:071b810ceb18 | 5577:0b6e7ae1e78f |
|---|---|
| 4162 (eq 'lambda (car-safe (cadadr form))) | 4162 (eq 'lambda (car-safe (cadadr form))) |
| 4163 (or | 4163 (or |
| 4164 (not (eq (setq form (cons (cadadr form) (cddr form))) | 4164 (not (eq (setq form (cons (cadadr form) (cddr form))) |
| 4165 (setq form (byte-compile-unfold-lambda form)))) | 4165 (setq form (byte-compile-unfold-lambda form)))) |
| 4166 (prog1 nil (setq form `(funcall #',(car form) ,@(cdr form)))))) | 4166 (prog1 nil (setq form `(funcall #',(car form) ,@(cdr form)))))) |
| 4167 ;; Sometimes the optimizer fails to unfold well-formed calls of the | 4167 ;; The byte-compile part of the #'labels implementation, above, |
| 4168 ;; form (funcall #'(lambda ...)); since we need it to do this for | 4168 ;; happens after macroexpansion and after the source optimizer has |
| 4169 ;; (declare (inline ...)) to work properly with labels, force that here. | 4169 ;; done its thing. When labels are to be made inline we can have code |
| 4170 ;; that looks like (funcall #'(lambda ...) ...), when the code that | |
| 4171 ;; the optimizer saw looked like (funcall #<compiled-function ...> | |
| 4172 ;; ...). | |
| 4173 ;; | |
| 4174 ;; So, the optimizer doesn't have the opportunity to transform the | |
| 4175 ;; former to (let (...) ...), and it's reasonable to do that here (since | |
| 4176 ;; the labels implementation doesn't change other code that would need | |
| 4177 ;; running through the optimizer; the lambda itself has already been | |
| 4178 ;; through the optimizer). | |
| 4179 ;; | |
| 4180 ;; Equally reasonable, and conceptually a bit clearer, would be to do | |
| 4181 ;; the transformation to (funcall #'(lambda ...) ...) in the | |
| 4182 ;; byte-optimizer, breaking most of the #'sublis calls out of the | |
| 4183 ;; byte-compile method. | |
| 4170 (byte-compile-form form) | 4184 (byte-compile-form form) |
| 4171 (mapc 'byte-compile-form (cdr form)) | 4185 (mapc 'byte-compile-form (cdr form)) |
| 4172 (byte-compile-out 'byte-call (length (cdr (cdr form)))))) | 4186 (byte-compile-out 'byte-call (length (cdr (cdr form)))))) |
| 4173 | 4187 |
| 4174 | 4188 |