Jonathan Simpson wrote: > Raymond Toy wrote: > >> >> You might want to do >> >> (declaim (inline make-vec3)) >> >> This allows make-vec3 to be inlined, and that means the args to >> make-vec3 don't have to be boxed up, which, I think, is what is the >> compiler notes for the last two calls to make-vec3 are about. >> >> Ray >> > Thanks. That did indeed take care of those three pesky notes. Do you > happen to know why the compiler can't deduce the types of the > make-vec3 args? Am I incorrect in thinking that the compiler should > be able to determine that it is dividing 2 double-floats in this case, > and that 2 double-floats equal another double-float? > It can and does determine the args are floats. The problem is that make-vec3 (like all functions) expects the args to be boxed, so normalize boxes them before calling make-vec3. By making make-vec3 inline, the boxing doesn't have to be done.
> Also, I noticed something else strange. If I use "(declare (inline > make-vec3))" inside the normalize function instead of declaim, it > doesn't work. Does declare work with inline? > This, I'm not sure about, but I think it's too late then. To inline a function, the source needs to be around and I think it's gone by then. By declaiming it inline, the compiler is instructed to keep the source of the function around for inlining. You might want to look in the CMUCL User's manual which explains some of this as well as maybe-inline which might be useful. With maybe-inline, the function isn't necessarily inlined, but could be. Then you could declare it inline as needed to get it inlined. Ray
