2011/11/7 Jeff Law <l...@redhat.com>: > -----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?
Well, to model this before TER makes sense. Nevertheless we have here some issues about transformation from gimple to RTL in terms of adjusting code in a way cfgexpander does the simplest form of transformation. As code-transformation is pretty much tied to C-tree in dojump. Some bits in dojump we need to touch anyway, as otherwise cfg-expander will destroy done BC-optimization. > 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. I would suggest that I use for 4.7 here get_gimple_for_ssa_name. In fact I have modified the patch for testing SA.values and tested it with success. >> 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. Agreed. >> >> 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. Sure. A more general question, which was raised by Richi here. For BC optimization it is of course interesting to know real instruction-costs and not just guessings. The current code in fold-const guess a bit too optimistic, the code in that patch is in some cases too pesimistic. So is there a facility to get prediction of instruction-costs on gimple-tree? I would say this isn't possible, as here we would need final RTL form to tell this, isn't it? Kai
