Hi Jeff, Richard. None of the RTL optimzers look at TRAP_IF w.r.t optimiizations.
I've decided to add some code to cprop.c and simplification primetives to simply_rtx () this do work once I fixed cprop to run on my testcase whicg only had functiions which 3 blocks currently it think theses nothing to do. I'jj submit a patchseparately for that. I'm currently tracking done a latent bug the cfg cleanup code which triggers a control inside basic block abort due to a (trap_if ((condtion) (const N)) being correctly optimized to ((trap_if (const_int 1)(conts_int N)). I ensure that when the condition is optimized to (const_int 1) that the block gets split after the unconditional trap satisfies control_flow_insn_p () predicate. The splt wroks so that the unconditional trap_if is the last instruction n its block but when cfg cleanup is run later it undoes this split and merges the blocks again thus triggering the verify_flow abort. Anyone know the rational (if any) for treating unconditional traps as control flow but not conditional traps. I would have expected them to be treated the same w.r.t flow control unless the condition is (const_int 0). Graham
