------- Comment #13 from amylaar at gcc dot gnu dot org 2006-08-25 16:33 ------- (In reply to comment #12) > As far as I can see, the i387 mode switching is already completely broken, > because it treats the different modes of a single mode-switchable entity > as separate entities.
On second thought, this can work with the current implementation of mode-switching using pre_edge_lcm, since it will never insert a computation in a path if it hasn't been there before. If there is a block with successors that have different mode requirements, hoisting any computation to its predecessor edges or above would cause a dead computation on at least one path through the sucessor edge which needs the other mode. So the calls to make_preds_opaque are not actually accomplishing anything, and we could compute all modes with a single pre_edge_lcm call. On the other hand, a more sophisticated code motion implementation would recognize when inserting a computation on an infrequent path can avoid doing it on a more frequent path. And then, the incorrect use of the mode switching interface in the i386 port could become a manifest bug. For any transparent sub-graph, considering the expression anticipatable in this graph is beneficial if the sum of the frequencies of outgoing edges on which the expression is anticipatable is larger than the sum of the frequencies of incoming edges on which the expression is not available. So the main problem for a code motion pass that takes edge frequencies into account appears to be to find heuristics how to identify transparent subgraphs which should be checked - a naiive algorithm to try all subsets of nodes would be exponential. On the other hand, checking only subgraphs which are interconnected as a list and have no connection to other transparent nodes except in head and tail, and could be expanded at their tail (alternatively: at their head) only in the form of a longer list, can be done with a greedy algorithm which checks only O(number of nodes) nodes. (Traverse all nodes to find nodes which are tail / head of maximum lists, drop nodes at the bottom if it increases the tally, for a positive tally, if adding a new node would decrease it, remember current list. When current tally becomes negative or the list can't be extended, check for remembered list.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28764
