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

[Xinliang David Li <davidxl@google.com>]

>> I want propose a more general solution.
>>
>> 1) Generic Annotation Support for gcc IR -- it is used attach to
>> application/optimization specific annotation to gimple statements and
>> annotations can be passed around across passes. In gcc, I only see
>> HISTOGRAM annotation for value profiling, which is not general enough
>> 2) Support of CallInfo for each callsite. This is an annotation, but
>> more standardized. The callinfo can be used to record information such
>> as call attributes, call side effects, mod-ref information etc ---
>> current gimple_call_flags can be folded into this Info structure.
>
> I don't like generic annotation facilities.  What should passes to with
> annotated stmts that are a) transformed, b) removed?  See RTL notes
> and all the interesting issues they cause.


Then how do you store information that needs to be passed across
optimization passes -- you can not possibly dump all of them into the
core IR. In fact, anything that is derived from (via analysis) but not
part of the core IR need to worry about update and maintenance. In
current GIMPLE, we can find many such instances -- DU chains, Memory
SSA, control flow information, as well as flags like visited,
no_warning, PLF (?), etc. Have a unified way of representing them is a
good thing so that 1) make the IR lean and mean; 2) avoid too many
different side data structures.  The important thing is to have a good
verifier to catch insanity and inconsistency of the annotation after
each pass.

Thanks,

David


>
>> Similarly (not related to this discussion), LoopInfo structure can be
>> introduced to annotate loop back edge jumps to allow FE to pass useful
>> information at loop level. For floating pointer operations, things
>> like the precision constraint, sensitivity to floating environment etc
>> can be recorded in FPInfo.
>
> Yes, the idea is to keep the loop structures live throughout the whole
> compilation.  Just somebody needs to do the last 1% of work.
>
> Richard.
>
>> T
>>
>>
>>>>> 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.
>>>
>>> Ah, indeed.  I hadn't thought about the tuning for different variants
>>> as opposed to enabling HW features.  So the interface for overloading
>>> would be sth like
>>>
>>> enum X { Foo = 0, Bar = 5 };
>>>
>>> enum X select () { return Bar; }
>>>
>>> void foo (void) __attribute__((dispatch(select, Bar)));
>>>
>>
>> Yes, for overloading -- something like this looks good.
>>
>> Thanks,
>>
>> David
>>
>