On Thu, Aug 07, 2014 at 12:29:34PM +0200, Jan Hubicka wrote: > > > > > > 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.
err yeah, I guess we'd need to rework things so front end just creates functions for each variable and then middle end pass creates function that call all of them if necessary. > 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) yeah, doesn't seem that hard. Trev > > Honza > > > > Trev > > > > > > > > Richard.
