> > I think that was one reason crtl was introduced ... to avoid an indirection > through cfun.
Main reason why I introduced crtl was to get struct function less bloated. RTL data live for only one function body at a time. It is useless to store them in a datastructure that is allocated at parsing time and freed at very end of compilation. I never did really serious analysis on performance implications of having crtl a static viarable or pointer or pointer from cfun. With current threading efforts, I guess we can either make RTL optimizers to have their own RTL context (i.e. crtl pointer passed everywhere) or just have crtl pointer in cfun (and get extra indirection + waste 8 bytes on every function body). > > I indeed welcome the effort to make all 'cfun' uses explicit. Even more > welcome > is reducing the number of 'cfun' references ;) Like giving all gimple/rtl > pass > execute () / gate () functions a struct function argument (or even > better abstract > that so we can add more context transparently later, like dump_file / > dump_flags). Yep. One of issues is that for IPA/RTL/Gimple passes the notion of context is always slightly different and not exactly matching the purpose of a function in the IL/symbol table. Honza
