Jim Wilson <[EMAIL PROTECTED]> writes: > It seems odd that cfgrtl allows a conditional trap inside a basic block, > but not an unconditional trap. The way things are now, it means we need > to fix up the basic blocks after running combine or any other pass that > might be able to simplify a conditional trap into an unconditional trap. > > I can work around this in the IA64 port. For instance I could use > different patterns for conditional and unconditional traps so that one > can't be converted to the other. Or I could try to hide the conditional > trap inside some pattern that doesn't get expanded until after reload. > None of these solutions seems quite right. > > But changing the basic block tree during/after combine doesn't seem > quite right either. > > The other solution would be to fix cfgbuild to treat all trap > instructions are control flow insns, instead of just the unconditional > ones. I'm not sure why it was written this way though, so I don't know > if this will cause other problems. I see that sibling and noreturn > calls are handled the same way as trap instructions, implying that they > are broken too.
I think the current cfgbuild behaviour is just to avoid putting a barrier in the middle of a basic block. A conditional trap instruction is not necessarily a control flow instruction for the compiler--it's similar to a function call which may or may not return. An unconditional trap is similar to a function call which is known to not return. I guess the difference is that combine can't turn a function call which may or may not return into a function call which will not return. Since traps are uncommon, and since you can't do a lot of optimization around them anyhow, it's probably OK to make them always return true from control_flow_insn_p. At least it's worth trying to see if anything breaks. Ian