On Nov 24, 2007 4:00 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 24, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > > > And it has to handle this new case everywhere. > > I've already explained why this isn't true. It's not even close to > being true. In fact, I've chosen this representation *precisely* > because I reasoned it would lead to the least global impact. Of > course you can refuse to believe that and point at the changes I had > to make as alleged counter-proof, failing to notice how many other > locations I haven't had to change and that just work because adjusting > other instructions after transformations is precisely what all > transformation passes already do.
It also makes some things easier - for example during inlining of a function body we re-map all DECLs in the inlined copy. With an on-the-side representation you have to ensure to make the same mapping explicitly, with DEBUG_INSNs the mapping is automatically done during the copying of the IL. A similar problem with using SSA_NAME definition points to store information is using the renamer to rename a variable that already has SSA_NAMES (which is IMHO bogus, as we do not detect the errorneous case of overlapping life-ranges - but ignore that for now) - in this case you need some magic to transfer the on-the-side debug information from the old SSA_NAMEs to the new ones (where possible). Just to mention a few problems we are running into ;) Richard.
