> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jan Hubicka wrote on 05/04/06 08:36: > > > If you are interested in some sort of integration of changes in IPA > > branch (IE whole program in SSA form), I can probably prepare sort of > > merge patches for review (pretty much as I intend to finally do in next > > development cycle). > > > Yeah, that'd be nice. Some of these changes are individually pretty > substantial, so I wonder whether it'd be better to have them in separate > branches to simplify integration.
I will definitly maintain the IPA branch till next release cycle so the changes can be integrated possibly earlier before the gimple reorganization converge to something. (honestly I have no idea how long this will take, but I take your promise of 12 weeks ;)) > > > It would be nice to have this in mind when designing datastructures so > > we won't end up with sollution having limitations of SSA to single > > function body (for example in current implementation the variable > > annotations are quite an offenders as they are shared across functions > > for static variables but contain function local datastructures). > > > Yes, another thing that I now see that is implicit with the removal of > on-the-side data structures is the gradual removal of language hooks, or > the inclusion of enough original language information to recover from a > stream. Yep, language hooks are going to be fun. > > > I did some testing of memory consumption for my gccsummit paper and it > > looks like (quite suprisingly I would say) current IPA branch is not > > noticeably worse in memory consumption than mainline (ie the conversion > > to SSA and early optimizations don't expand IL too much). > > > Nice. Looking forward to this. > > > I don't however build the aliasing info, just do the SSA before first > > alias pass. I am not sure whether we want to build SSA representation > > of aliasing for whole program (mem-SSA or not) is good idea. Perhaps > > just making aliaisng aware early local pass, then removing the virutal > > operands and rebuilding aliasing in late pass is easier way to go, but > > with proper design of datastructures I guess it won't be dificult to > > experiment with it later. > > > Is it because of all the virtual operands? Or is the information hard > to keep for multiple functions? Well, I would expect vops to be important portion of our memory footprint, but I don't have numbers for that (and I would expect that for example SSA_NAME shows on the list more than it actually did, so the guesses are not really good here). Anyway the main dificulty here is that for built aliasing info you need variable annotations and those are shared. Perhaps also keeping the info up to date during inlining might be bit tricky (for local variables inlining is really nice not inventing PHIs and such, but for statics this is more fun so I guess we would end up marking them all for renaming anyway). I am also not quite convinced how much the SSA form aliasing helps the IPA passes that are usually interested in rather straighforward analysis of function body, so aliasing don't seems to be top priority here. So I simply chosed to not mess with this for initial implementation. Honza > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (GNU/Linux) > > iD8DBQFEWgNjUTa2oAUaiwQRAt3VAJ40n4uTok2563PvLYTSJbrcqF1tCQCePGRA > ZtjZOQrRz8AiUPwR5WtsVBw= > =f50m > -----END PGP SIGNATURE-----
