> > > > Probably not ;) > > > > But seriously it's a matter of a) keeping constructors for each > > variable separate and optimize them in GIMPLE, b) recognize > > resulting code that can be expressed with a initializer > > > > a) can be done with delaying inlining to IPA time and hoping > > that early opts do enough to perform the necessary simplification, > > b) needs a new pass (but I guess it shouldn't be _that_ hard...) > > I'm not sure totally skipping inlining in C++ is that great an idea > since most C++ ctors will end up calling things. Isn't it enough to not > inline the initializer for a variable into the file level function that > calls all the initializers, which you could do by internally apply > attribute noinline I guess. > > > I think we already have constructor functions marked specially, > > hopefully with a link to the initialized variable. > > I'd expect that's what DECL_STATIC_CONSTRUCTOR does, but I'm not sure > there's a link or where we could put one if there isn't.
If you mean language level static constructors, then it doesn't. C++ FE produce them and then wrap thems in static_construction functions that are the only having DECL_STATIC_CONSTRUCTOR calling the actual ctors. Should not be hard to add though. Need to read back why inlining would be undesriable here - not inliing ctors in general would indeed be problematic (preventing SRA and more stuff) Honza > > Trev > > > > > Richard.
