On 06/30/2015 03:46 AM, Bernd Schmidt wrote: > On 06/28/2015 04:15 PM, Chen Gang wrote: >> For bfin looping optimization, after lsetup optimization, it can have >> the correct lsetup related insns which causes gcc_assert for jump_insn. > > I've been debugging this for a bit, and at least the explanation of the > patch is wrong - it's finding an LSETUP for a different loop. There > seems to be an inconsistency in the CFG, and it looks like it's caused > by the unusual (?) situation that both arms out of a conditional branch > lead directly to a hwloop candidate. >
For me, the more details are: - The insns have 2 loops which can be lsetup optimized. - After hwloop_optimize finishes 1st lsetup optimization, it generates new lsetup insn which appends to jump insn in the basic block (which causes the insns are not 'standard' but OK for code generation). - In 2nd lsetup optimization, hwloop_optimize found the insns are not 'standard' (they are generated by hwloop_optimize itself in 1st lsetup optimization), so gcc_assert(). So hwloop_optimize can give up lsetup optimization for the 'unstandard' insns, at present, all things will be OK. If we want to try perfect, we can let hwloop_optimize can process the 'unstandard' insns for lsetup optimization. But excuse me, I am not quite familiar with gcc internal or bfin (so I am not suitable for it). > So, not OK until further investigation I think. > If necessary (what I said above is incorrect), I shall continue to analyse. Thanks. -- Chen Gang Open, share, and attitude like air, water, and life which God blessed
