> > I can think of some more-or-less obvious high-level forms, one would > for example simply stick a new DISPATCH tree into gimple_call_fn > (similar to how we can have OBJ_TYPE_REF there), the DISPATCH > tree would be of variable length, first operand the selector function > and further operands function addresses. That would keep the > actual call visible (instead of a fake __builtin_dispatch call), something > I'd really like to see.
This sounds like a good long term solution. > > > Restricting ourselves to use the existing target attribute at the > beginning (with a single, compiler-generated selector function) > is probably good enough to get a prototype up and running. > Extending it to arbitrary selector-function, value pairs using a > new attribute is then probably easy (I don't see the exact use-case > for that yet, but I suppose it exists if you say so). For the use cases, CPU model will be looked at instead of just the core architecture -- this will give use more information about the numbrer of cores, size of caches etc. Intel's runtime library does this checkiing at start up time so that the multi-versioned code can look at those and make the appropriate decisions. It will be even more complicated for arm processors -- which can have the same processor cores but configured differently w.r.t VFP, NEON etc. > > For the overloading to work we probably have to force that the > functions are local (so we can mangle them arbitrarily) and that > if the function should be visible externally people add an > externally visible dispatcher (foo in the above example would be one). > For most of the cases, probably only the primary/default version needs to be publicly visible .. Thanks, David > >>> Now, a language extension to support multi-versioning should be >>> completely independent on any IL representation - with using >>> a builtin you are tying them together with the only convenient >>> mechanism we have - a mechanism that isn't optimal for either >>> side IMNSHO. >>> >> >> Yes -- they don't have to be tied -- they just happen to suite the >> needs of both ends -- but I see the value of the latest proposal >> (overloading) above. > > I did realize that using builtins was convenient (been there and done > the same for some experiments ...). > > Richard. >
