-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/11 09:14, Richard Guenther wrote:
>> >> Well, not that I noticed that I missed here any freedom. In >> what cases you mean I would need here freedom to create new >> ssa-statements? > > You lookup SSA_NAME_DEF_STMTs of SSA names - you cannot do that for > SSA names that have been coalesced with others. Instead there is > get_gimple_for_ssa_name which may return NULL. Just so I understand what's going on here. Kai wants to move this code into the expanders which obviously run after TER. Once TER has done it's job we can't depend on SSA_NAME_DEF_STMT in any meaningful way. I haven't looked closely at Kai's implementation (I've just helped with some benchmarking stuff), but would it make sense to leave this stuff in gimple, but make the transformations we want just prior to TER? Alternately, the code could use get_gimple_for_ssa_name and bail out if it returned something non-useful, such as NULL? Obviously this would be the only choice if the code were intimately tied to the cfgexpand bits. > Kai writes: >> So for the upcoming 4.8 I will happily work on a more improved >> version, which can handle the switch-lowering, too. What I think Richard was suggesting is a general approach where we can tie in switch lowering and other lowerering or cost dependent transformations. I don't think he's asking you to add switching lowering, just build what you're doing in such a way that someone could add switch lowering later. My concern is that the more things you try to fix and handle, the more complex the patch is going to become and the more difficult to review, benchmark & analyze. So my preference would be to try and get the current improvements into a suitable form & approved before tackling something like switch lowering. > > Well, trapping statements are properly marked and operands never > have side-effects in gimple. So the situation is very easy - > never collect these kinds of operations in such "affine > combination" - you couldn't do anything with them anyway. Right. Kai, I think it's this property of gimple that Richi wants you to take advantage of. I think we've all agreed that doing this stuff on the pre-gimplified tress is difficult and against the general direction we want to go. But that does _not_ mean that doing this stuff on a gimplified tree is bad. In fact, gimple was designed to make this kind stuff easy to do. > >> So by this patch we already have a code-reduction of about 0.3% >> and for each extra-dynamical branch a much higher reduction of >> executed instruction as current approach shows. > > On which targets and for which benchmark? Kai may be referring the benchmarks I've been running for him using the framework I use to evaluate for jump threading and related changes. If so the process looks something like this: Build the trunk to get a baseline compiler. Use the trunk compiler to build a gcc-4.6.0 compiler (checking enabled) Then use the gcc-4.6.0 cc1 we just built to compile a bunch of .i files under the watchful eye of valgrind/cachegrind Apply patch Rebuild trunk Use the patched trunk compiler to build a new gcc-4.6.0 compiler Use the newer built gcc-4.6.0 to build the bunch of .i files under the watchful eye of valgrind/cachegrind Compare results. From valgrind we get # insns executed, # branches and a variety of other data. However, insns executed and branches are the most useful for the changes I'm tracking. There's certain limitations to this kind of testing that I have discussed with Kai, in particular valgrind doesn't tell us costs of insns or break them down further based on type. So we speculate an insn out of a conditional, linearize the code, eliminating some branching. The net result may be more total insns executed, but fewer poorly predicted branches executed. Jeff -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOuDNNAAoJEBRtltQi2kC7GpMH/2ABKFbjvPB5t/hjugL2XlNv qxYfZH/ySreP6oSeNn35VGmKB19jZYi9V3tPnkRxW6QY4YTHEAgDVRt4nuuQw+Mn bK78x7qtnYLIqzGY1Gp/QEq1EFz13sehfHEk4jWcoJcCrJJzJG9Y1I+mc5H4PRHU cclqUtkRsF9Eu+s24E/kiSpUV2d+C4yZgr8mmrnfp5Xh1MbeCJKg4JMbVuOHTLWB apAJF0LQQjOVl+eb4mtZTwOpew7NarJrcKMuh9O83IlRtsrk1pXUl2k2BtBnYTbc G0EHlQhiPqxpr57eMYX2XpGUp6NZ30FKLTA8VoK6nZimCRF1UiJBhM8Dh79h9dg= =mxTE -----END PGP SIGNATURE-----
