Comment 3 for bug 1903512

the code fragment has another problem now - it must materialize a list as input to make-array, so it has to box the float to put it in a list. (An SSC could always avoid making the list, but that's another issue. Sometimes we can, sometimes we can't)

The only way to prove that the notes are coming from part of the emitted code that definitely have to do with floating-point math where you've excluded - the extent possible - any other ostensible need to materialize a boxed would would be to rewrite the test case as something like this:
  (let ((a (make-array 1 :element-type 'double-float)))
     (setf (aref a 0) (nth-value 1 (ffloor num div))))
  a) ; and don't return the float, of course

That said, there is still float boxing because we're not actually able to inline ffloor.

So while the original report was about "unreachable code", the new note is about boxing because of the (OPTIMIZE SPEED) declaration.
This kind of complaint might broadly fall under a bug for making the compiler able to inline more floating-point operations. I'm not sure if you want to keep this open, but certainly the original subject line of "notes in FFLOOR" doesn't really convey that. And the reason we can't inline the floor operation per se is that ... well, the algorithm is crappy, to a certain degree.
Improvements to it are welcome. It might be interesting to see how the performance compares to the code emitted by a C compiler using trunc() plus a subtraction to obtain the remainder.