This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, May 6, 2011 at 7:57 PM, Xinliang David Li <davidxl@google.com> wrote:
>>> 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.

Well, as soon as you have a verifier it's no longer generic but _is_
part of the "core IL".  Similar to how EH info is part of the "core IL",
or alias info, or loop information.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]