* Raymond Toy [2012-06-22 04:36] writes:
I could use a bit of feedback regarding the names. Currently I use "typed calling convention" resp. "typed entry point" and for the regular entry point I use "external entry point" or XEP. For the :typed-no-xep case the naming is a bit misleading as the typed entry point is the only entry point and in the IR has the lambda-kind set to :external, i.e. the XEP is a typed entry. Is there a better word for it?
Sorry that I still haven't had a chance to look at your code or even play with it.
I find the :typed and :typed-no-xep hard to remember, though. Could it be :unboxed instead? That makes it pretty clear that you're using calling convention that supports unboxed args.
The only issue I have with "unboxed" is that the calling convention also supports boxed values, e.g. arrays, for which the type check was already done in the caller.
Also, how complex is it to keep track of this information so that the compiler can make the appropriate call?
I added a new info type in the globaldb that keeps track of the calling convention. Essentially one bit that says that this name should be called with the unboxed convention. Currently I do this in a way that is similar to how struct accessors/setters are inlined: when the compiler sees a call it recognizes that that name has the bit set and puts the function-info for %typed-call in the combination-kind slot. The ir2-converter for %typed-call then looks at the type for the global-var name. We keep track of the type anyway, i.e. this isn't new. The type determines the representation for the call. The other new information is the linker table. For callsites we also record the type. The callsites that call the same function and the same type share one entry. I expect that without redefinitions that all callsite of the same function will share a single entry. We also need to inspect the type of function objects during linking. Functions carry the type, expect if compiled with (optimize space). The only new bit here is that we disable the space optimization for the new calling convention. In the IR I need to mark some lambdas as unboxed entry points. Currently I put something in the lambda-plist for that. Right now, I'm thinking about making the unboxed entry a new slot of the optional-dispatch struct which might be a bit cleaner. There are a couple of new VOPs which must still be written for the non-x86 ports.
Oh, and is there a use case you're interested in where block compilation doesn't do what you want? (In my particular, hypothetical use case, I can see doing this with f2cl'ed code where the preferred technique is putting one Fortran function per file. But this seems to rather uncommon but would be very useful.)
Say we have a math library with dozens of functions that operate on floats. To get the benefits of block compilation, we would need to compile the library together with the caller of the library in one block. Also, if we change something we need to recompile the entire block. Yes, that's possible, but not very convenient. Helmut