Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

[Xinliang David Li <davidxl at google dot com>]

>
> 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.
>