Tristan Gingold <[EMAIL PROTECTED]> writes: > > I don't think it is appropriate to change the meaning of > > forwarder_block_p. And I'm not sure why you need that patch anyhow, > > considering the existing code in cleanup_tree_cfg_1. > Without that change, the rtl jump pass cleans the jump and all the > previous work is useless.
I see. Then I think we shoulid tweak the RTL jump pass along the lines of cleanup_tree_cfg_1. A function like forwarder_block_p is conceptually easy to understand. It becomes harder to understand if it turns into forwarder_block_when_optimizing_p. > > Also you should ideally add a test case. > The effects are only visible for the debugger. How to write a > compiler test case for this case ? For tree level changes, you do it by grepping the dump file. See many of the test cases in testsuite/gcc.dg/tree-ssa, and their use of scan-tree-dump. For RTL level changes, the dump files are harder to interpret. But maybe you could do it by compiling with -gdwarf-2 and looking for a .loc pseudo-op with the right value in the assembler file (using scan-assembler). I don't know if that would really work but it seems feasible at first glance. My concern, of course, is that this kind of change is fragile, and we want to make sure that it does not break accidentally. Ian
