surprising behavior of dynamic-extent in do forms

[Cyrus Harmon]

I'm seeing some surprising (to me at least) behavior caused by dynamic-extent declarations in do forms. Phoe on #sbcl reduced the issue to, roughly, the following test case:

(defun foo (startr endr)
  (let ((acc 0))
    (do ((i startr (1+ i))) ((> i endr))
      (declare (dynamic-extent i))
      (incf acc i))
    acc))

[note that this works without the acc stuff, I just used this to convince myself that this wasn't all just optimized away]

When I compile this form I get:
cd /home/sly/projects/clem/src/
1 compiler notes:

temp.lisp:37:5:
  note:
    could not stack allocate STARTR in: (DO ((I STARTR (1+ I))) ((> I ENDR)) (DECLARE (DYNAMIC-EXTENT I)) (INCF ACC I))
    --> BLOCK LET
    ==>
      STARTR

Why should the dynamic-extent declaration of i affect whether or not startr is stack allocated?

A trivial rewrite of this using loop does not trigger the same compiler note.

[Stas Boukarev (stassats)]

Because it's the initial value of I.

[Cyrus Harmon (ch-launchpad)]

Why is the behavior of do so different from:

(defun foo2 (startr endr)
  (declare (dynamic-extent startr))
  (let ((acc 0))
    (loop for i fixnum from startr to endr
       do (incf acc i))
    acc))

where, again, the initial value of i is startr, but I see no warning? I'm imagine I'm missing something obvious here.

[Stas Boukarev (stassats)]

There's no warning in your first form either.

And no notes for external entry point variables is a new thing, since in some cases it can be dxed at the call time now.

[Cyrus Harmon (ch-launchpad)]

Ok, I misspoke. note, not warning. I still don't see why the do form issues a note but the loop form doesn't.

[Stas Boukarev (stassats)]

The loop form doesn't even have any dynamic-extent declarations, so I'm not sure how you're comparing them.

[Charles (karlosz)]

We don't emit these kinds of notes anymore, because they are unactionable. It's better to use SB-EXT:STACK-ALLOCATED-P to check if stuff is stack consed.