On Sat, May 7, 2011 at 7:07 PM, Xinliang David Li <davi...@google.com> wrote:
> On Sat, May 7, 2011 at 5:46 AM, Richard Guenther
> <richard.guent...@gmail.com> wrote:
>> On Fri, May 6, 2011 at 7:57 PM, Xinliang David Li <davi...@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.
>
> The difference is that no-core IL can be thrown away anytime and be
> recomputed if needed.

The same is true for all of the "core IL" pieces I listed above apart
from maybe EH info.

Richard.

> David
>
>
>>
>> Richard.
>>
>

Reply via email to