On Mon, May 2, 2011 at 7:07 PM, Jeff Law <l...@redhat.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > This is merely an infrastructure patch in preparation for another > improvement in the jump threading code. It shouldn't affect the code we > generate at all. > > Let's consider this CFG (from a routine in cfgexpand.c) > > > A > / \ > B C > | / \ > | D E > | | / \ > | | F G > \| | > \| > H > / \ > I J > / \ > L M > | / \ > | N O > | | / \ > | | P Q > \| | > \| > R > > > As it turns out some blocks have the same condition (A,I), (C,M), (E,O). > But because of the merge block H, no threading is possible. What we > want to do is make 3 copies of H, each reachable from one predecessor of > the original H. > > To do this we need to know the edge into the joiner block so that we > can wire up the copy to the right predecessor. We need the outgoing > edge from the joiner block that is threadable and finally we need the > destination edge. > > This is a fairly simple extension to the existing code -- but we're > going to need the ability to store more information in the E->aux field. > Previously E->aux stored the destination edge for a jump thread. This > change allows E->aux to store additional data by changing it from a > single edge pointer to instead point to an array of edges. > > FWIW, the patch to make copies of H to enable threading is probably the > limit of what can be done with the current threader. I'm hoping to > start prototyping more generic path isolation code shortly. > > Bootstrapped and regression tested on x86_64-unknown-linux-gnu. > > OK for trunk?
For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends. I wonder if it makes sense to use a VEC instead (will the vector be of variable size?). Maybe wrap accesses to e->aux with a macro or some inline functions. Ok with the allocation change. Thanks, Richard. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJNvuTiAAoJEBRtltQi2kC75OAIAIe77UqINq3jUeKdYMZ/OII1 > +x+al4zcsx9YOCw6wdmMjWUS0Z9IcPmuKQIoPXtgq+R1qnADg5OnAiwKKZvdukIc > mhzbp+IBiDezFufv373shlp+hZtPN4QL73TDffWC4F9Eb7mYzADsIuAz2SIRcFVd > HB1UAxiiD8nUA4/uVa8Ree4PA91u8M3OGpC2iwW3eq/sBIzbdCs+TEI2Nps6qDLa > qmjNab/Zunh5OadJgtGB7Uk9pBv/I6zsbHmHCcZjRyOMyg8UXMCJTDjqpgUWJHAg > vIast5ayTI45cwJO69qykqZdrmrNUDpOHf/93HjNMhJvdSqPkB7eHiBvlcy2RdA= > =QsON > -----END PGP SIGNATURE----- >