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