> Sadly no. Most of these (the *agu* ones) are also reached from final. > For example: > > movdi_internal -> ix86_use_lea_for_mov -> ix86_lea_outperforms -> > distance_non_agu_define -> distance_non_agu_define_in_bb > > Likewise for movsi_internal, and zero_extendsidi2. For the > mov?i_internal define_insns, it's been like that since at least > r181077 (November 2011).
OK, I double-checked, but obviously not sufficiently. > I must admit I was surprised by that, too. It may have been > coincidence that it worked when this patch was (IMHO wrongfully) > accepted. Someone got away with it because i386 calls > compute_bb_for_insn in its machine-reorg, and does *not* call > free_bb_for_insn, leaving the BLOCK_FOR_INSN pointers in place all the > way through final. There are no passes between machine-reorg and final > that run for i386 and damage the CFG because split5 doesn't run on > i386 (because of STACK_REGS) and the other passes, like > shorten_branches, don't modify the insns chain. I see, thanks for the analysis. > I think you're taking a too dbr_schedule-ports point of view on this > There are already targets that never really destroy the CFG at all, > all the way through final. Few ports that do destroy it, destroy it as > badly as dbr_schedule. Most only have innocent "damage" that are > really just deficiencies of verify_flow_info. I cannot deny that I care about the architectures with delay slots and think that starting to put them aside is the beginning of a slippery slope. Unlike in other compilers, a few of them are first-class architectures in GCC and I think that this should be preserved, even if they are less sexy these days. > It is feasible in the short term -- as in: right now -- for some > targets. Is it possible in the short term for all targets? No. But > you've got to start somewhere. I firmly believe that port maintainers > will not find it hard to make it work for their ports, dbr_schedule > ports aside and that's a problem I'm trying to solve (while at it: > ping**2 for http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00595.html > that I need to move ahead). Your efforts are much appreciated but replacing dbr_schedule is a huge undertaking which may take longer than expected and I don't think that we have any guarantee on its outcome. > I've considered that path, too, but I opted against it because we end > up with pass_free_cfg being called from the majority of targets, and > verify_flow_info calls in targets that really maintain a proper CFG. > It also results in unnecessary damage from split5 for targets that > have a valid CFG up to that point. But what worried me the most is > that this approach made it more difficult to see what ports actually > are CFG-safe. I chose the new target hook approach because you can > just grep for the CFG-safe target hook to see what ports are already > OK and which ones are still TODO. Sure, but IMO one very probable future is that the CFG-safe target hook will be quickly enabled for x86, PowerPC and ARM, at which point people will start to add CFG-based enhancements to the late generic passes (or entire new CFG- based late generic passes), leaving the architectures with delay slots dead in the water. > But if I still haven't convince you, I'll prepare a patch along those lines. I honestly cannot approve a patch that segregates the architectures with delay slots from the others. Now, if another maintainer thinks this is the right call to make here, I won't oppose. -- Eric Botcazou
