> But now I am facing with a new instruction which will put the result > in a single register,and thus GCC want to do GCSE on this > instruction.GCC will treat si1%si2 as a loop invariant.So si1%si2 was > moved out of the loop,just before the execution of function foo();as > si2 is equal 0,there occurs a trap which shouldn't have occurred > according to the original semantic.
This happens for other targets as well, see the audit trail of the PR. > I am considering a solution:in a certain basic block,if there > exists a function call rtx(which might exit or even trap in > advance),then we shall not do GCSE optimization on the following rtx > which might trap(see rtlanal.c:may_trap_p()).But it seems the cost is > expensive,and I am not quite sure whether or not it works. Any attempt along these lines would most likely pessimize the common case. This PR is a pathological case that doesn't come from real life and fixing it properly is hard, so I wouldn't bother about it. -- Eric Botcazou
