-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/11 12:31, kevin diggs wrote: > Hi, > > Would it be correct to say that the (target machine influenced) RTL > representation has ... less intelligence (wrong word?) than the tree > representation (GENERIC or GIMPLE)? Sort of like describing a circle > with a point and radius or as a polygon? They're not directly comparable. For some things gimple is a better IR, for other things RTL is a better IR. > > I am trying to figure out where to place this optimization? Early > where the tree is still available or purely in the RTL (where from > various reading most other optimizations take place)? It'll depend on what kind of optimization you're doing. > > Can someone suggest a good optimization (available in the 3.4.6acene > era) to study? Similarly. To be able to suggest an optimization pass to look at for reference, we need to know more about the optimization you're proposing. > > Finally, does the 3.4.6 tree representation have a name? Was it called > GENERIC? Or is that 4.x only? Are they similar (4.x is a revision of > 3.4.6)? Prior to GCC 4, trees were trees, there was no gimple or generic. In fact, it's exceedingly difficult in compilers prior to GCC 4 to do any optimizations which require looking at multiple statements at any level other than RTL. > The optimization I am working on's goal is to change the way that > string constants are accessed by architectures like the register > adequate PowerPC. More details please. > > I guess another way to ask is, are string literals easily identifiable > in RTL (I've only started looking at RTL)? They're easier to identify as trees, as RTL, they may be sitting in the constant pool, a register if they're only a few chars, etc. At the tree level, strings will look like strings and they'll be easy to identify. jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNmhj9AAoJEBRtltQi2kC7gQAIAIirV/XGcLx8GbdmNi6wYyNr 7jo55wUjZqJfYMjWg/3DQqFHAoa2C2wwvGvJmNeWUNqJrKai0e0oYMSMsSMvAjkO p0+CKR+AJRiC0CjBEkLCOV9H9i7OeHxInNFAcp9ZgOZNa0ojpIFGWCPuxi8kX4ib dWGBjJ2MhNgniYgcNczcFyxkpd/2MKuroQoj5Kml9kK9QsaGGJ9FdpDLaxzxRDGQ J8wzNXiSOx/A1iOieuNzn//oyEuVXlrA0ZKn0BLQpe/ksPBIVPiw98vnaSJCUMGA oZty8Ro2YP+XL23U5LfJPkCoBz4qwZc1lzoNJxeagtJ/M+iFMtvFDLcbSSJRCgM= =BKhp -----END PGP SIGNATURE-----
